gradle

[digitalsanctum]

Just saw an announcement about Gradle on TSS:

http://www.theserverside.com/news/thread.tss?thread_id=49165

Now would be an excellent time to announce a release.

--
-Shane

[Assaf Arkin]

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.  We're hoping to make it through on the first pass, so we're checking
all the little details (licensing in particular) before starting.


A lot of you would just want to do gem update, get the new release and start
using it.  These gem update releases are made through RubyForge, by me.
 They are not official Apache releases, there's no process for making these
releases, we don't even have to vote on them.

Regardless, I think we want to vote on both releases together.  For a couple
of reasons.  First, putting anything up for vote means more people are
looking into the code and testing it, so we get more stable releases.
 That's the benefit of voting on RubyForge releases.  Second, life is easier
if whichever package you download, they're both the same.


So we're waiting to clear a couple of licensing issues, before starting the
formal vote on buildr-dev.  We'll need the actual gem, zip and tarball
packages to vote on.  If that gets approved (takes 72 hours), 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.

I assume to most people it doesn't sound like much of a difference, but
enough that I wanted to bring it up for discussion.

If we follow the first process, we can make unofficial releases as well,
this could come in handy if we need to do a quick release for a troubling
bug fix.  There's also the possibility that some releases will not get
approved (usually licensing issues).  In either case we can follow up with
another official/unofficial release that fixes those issues.

The second option guarantees that each RubyForge release is only for the
convenience of using gem update, and is otherwise backed by an official
Apache release.


What do you all think about that?

Assaf

[Gilles Scokart]

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

[Matthieu Riou-5]

On Thu, Apr 24, 2008 at 12:27 AM, Gilles Scokart <gscokart@...> wrote:

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

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
>

[Matthieu Riou-5]

On Thu, Apr 24, 2008 at 8:30 AM, Matthieu Riou <matthieu@...>
wrote:

> On Thu, Apr 24, 2008 at 12:27 AM, Gilles Scokart <gscokart@...>
> wrote:
>
>> 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.
>>
>
> 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
>>
>
>

[Erik Hatcher]

On Apr 24, 2008, at 11:30 AM, Matthieu Riou wrote:

> Ruby [sic - Buildr] 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.

I started Ruby work last year for Solr here:

   <http://svn.apache.org/viewvc/lucene/solr/trunk/client/ruby/>

solr-ruby is a Ruby library interacting with Solr that bundles into a  
gem and even bundles into a Rails plugin directory structure.  I've  
been manually updating RubyForge with local builds of the gem as  
unofficial (< 1.0) builds.

flare is a RoR plugin (enabling faceted browsing, full-text search,  
Ajax suggest) for Solr.

I'd love to have Apache support Ruby infrastructure-wise in terms of  
being an official gem server, etc.

So count me in for supporting (and helping if I can) in these efforts  
to Rubyify Apache a bit more :)

Re: Buildr - I've yet to give it a serious try, but I've been  
following the e-mail list and have tinkered with a much older version  
of it a while ago.  Great stuff!

        Erik

[Ittay Dror]

Shane Witbeck wrote:

Just saw an announcement about Gradle on TSS:

http://www.theserverside.com/news/thread.tss?thread_id=49165

Now would be an excellent time to announce a release.

Do you have a comparison of Buildr and Gradle?

Thank you,
Ittay