[ruby-core:17413] Re: Time for a release management committee?

Charles Oliver Nutter wrote:
> It seems like recent problems with patchlevel and minor 1.8 releases 
> mean that there's too much for one release manager to track. Urabe has 
> been doing a great job, but tracking both 1.8.6 patchlevels and 1.8.7 
> releases requires more help. And I believe we need to start giving all 
> the alternative implementations a say in the Ruby release process, since 
> it directly impacts our compatibility.
> 
> So I suggest the following:
> 
> - Each implementation should nominate one member to serve as part of a 
> release committee.
> - Changes to patchlevels and minor 1.8 versions will go through the 
> committee before getting into a release.
> - If the committee agrees the change is justified, it can proceed. 
> Otherwise, it needs to be examine and possibly reverted or removed.
> 
> This would allow all stakeholders in the "Ruby specification" to have a 
> say in what changes are allowed.
> 
> For my part, I nominate Vladimir Sizikov from JRuby. And I can't imagine 
> a better choice from Rubinius than Brian Ford.
> 
> What about this idea?
> 
> - Charlie
> 
> 

Well ... I don't think it's so much a lack of manpower as a lack of 
hardware for the insane amount of testing and SCM automation that needs 
to be done. So ... suppose we limit this to everybody that can run 
Rails. That way, we get more test suites. So that's MRI 1.8.6/1.8.7, 
IronRuby, jRuby, and Rubinius, right? Or does KRI run Rails now?

What's the hardware/OS collection required? At least MacOS, Linux, 
Windows, Solaris and one of the server-grade BSD variants. How many 
different versions of GCC need to be tested? There's only one platform 
that needs to be available for jRuby testing -- the latest JVM. Would we 
need to test on anything besides x86, x86_64, and SPARC?