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:30:50 GMT
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.

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