On 23/04/2008, Assaf Arkin <
arkin@...> 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.
--
Gilles Scokart