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. 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 >
