On 24/04/2008, Matthieu Riou <[EMAIL PROTECTED]> wrote: > On Thu, Apr 24, 2008 at 12:35 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > > On 23/04/2008, Matthieu Riou <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 23, 2008 at 1:22 PM, 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. 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
