buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Release process [WAS Re: gradle]
Date Thu, 24 Apr 2008 21:49:34 GMT
On 24/04/2008, Matthieu Riou <matthieu@offthelip.org> wrote:
> On Thu, Apr 24, 2008 at 12:35 AM, Gilles Scokart <gscokart@gmail.com> wrote:
>
>  > On 23/04/2008, Matthieu Riou <matthieu@offthelip.org> wrote:
>  > > On Wed, Apr 23, 2008 at 1:22 PM, 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.  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?
>  > >  >
>  > >
>  > >  I like 2 much better. Having potentially different binaries and/or
>  > tarballs
>  > >  between what's downloadable at Apache and Rubyforge is going to be a
>  > pain.
>  > >
>  > >  Otherwise I agree with everything you said. Just a little technicality:
>  > as
>  > >  far as the ASF is concerned, we only vote on the source tarball. The
>  > binary
>  > >  is just a convenience offered to the users.
>  > >
>  >
>  > It is true that the vote focus on source tarball (I think even some
>  > PMC even vote on an svn tag).
>  >
>
>
> An svn tag isn't signed, I wouldn't consider that good practice.
>
>

Me neither, the problem is that the community has no control on what
is happening between the svn tag and the tarball being produced.


>
>  >
>  > However the binary distribution has to
>  > follow some rules as well (licenses and notice file must be present
>  > also, for instance).  So I would submit it also with the vote.
>  >
>
>
> Agreed. I was just pointing out that what *really* makes the release is the
>  source distro. See:
>
>  http://markmail.org/message/hgwdjaayxj5crzif
>
>  But yes, binary releases should also be submitted for the vote to make sure
>  they're kosher.
>
>  Matthieu
>
>
>  >
>  >
>  > --
>  > Gilles Scokart
>  >
>


-- 
Gilles Scokart

Mime
View raw message