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.

-- 
Gilles Scokart

Reply via email to