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