buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: gradle
Date Thu, 24 Apr 2008 15:46:26 GMT
On Thu, Apr 24, 2008 at 8:30 AM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> On Thu, Apr 24, 2008 at 12:27 AM, Gilles Scokart <gscokart@gmail.com>
> wrote:
>
>> On 23/04/2008, Assaf Arkin <arkin@intalio.com> 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
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message