On Thu, Apr 24, 2008 at 8:30 AM, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 24, 2008 at 12:27 AM, Gilles Scokart <[EMAIL PROTECTED]> > wrote: > >> On 23/04/2008, Assaf Arkin <[EMAIL PROTECTED]> wrote: >> > A bit of explanation for what goes next (Matthieu, correct me if I got >> > anything wrong), and I'm working this form back to front. >> > >> > We want to make 1.3 the first official Apache release of Build. That >> means >> > making sure there are no outstanding issues, all test cases pass, >> > documentation is up to date, and we don't have any licensing issues. >> The >> > official release is held up to the Apache standard, and will be posted >> on >> > the incubator Web site. >> > >> > To make that happen we need a formal vote o buildr-dev, followed by a >> formal >> > vote in the PMC (Project Management Committee), that's 72 hours for >> each >> > one. >> >> Actually, it is 72 hours, AND at least 3 +1 ... That make sometimes a >> big difference, mostly for the official vote done by the IPMC (which >> is the officical one. The first one done by the PPMC is mostly for >> learning the process) >> >> >> >> > we have two >> > options: >> > >> > 1. Immediately make a RubyForge release. Separately follow with PMC >> vote >> > to make an official Apache release (another 72 hours). The Web site >> will be >> > updated as soon as the RubyForge Gems are available. >> > >> > 2. Follow with a PMC vote, when that gets approved, make both >> RubyForge and >> > Apache releases. >> > >> >> With the first aproach, that means that you personally take buildr and >> redistribute it by yourself. >> If you do that, I would expect to have a clear indication that it is >> NOT Apache Incubator Buildr 1.3, but that it is buildr-arkin-20080424. >> >> Do you see the difference? >> >> Personally, I would clearly go to the aproach 2 by respect for the >> people who are working to review Buildr 1.3 and who will feel bypassed >> if you make your own parallel release. >> > > Just to clarify, it's not about making "your own parrallel release". Ruby > is the first Apache project in Ruby and its binary release is going to be a > Ruby Gem. The way gems are distributed is by uploading them on Rubyforge, at > least as long as Apache doesn't have its own gem server (which would be > entirely possible but that's another story). That's very much like Maven > artifacts (mirrored on maven.org) I believe, except that for Maven the > process has been streamlined because it's already common practice. > Argh. s/Ruby is the first/Buildr is the first/ > > That being said, I agree with you that we should wait for the vote and the > official release to upload to Rubyforge for all sorts of reason. It's just > nice that Assaf asked for guidance :) > > Cheers, > Matthieu > > >> >> -- >> Gilles Scokart >> > >
