On Wed, Apr 23, 2008 at 1:34 PM, 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. I'm looking into this right now, but I don't think it will be a problem: 1. Create all package files, changelog and signature. 2. Move those over to a public folder, where we can vote on them. 3. Following buildr-dev vote, upload these to RubyForge. 4. Following PMC vote, upload these to Apache. Assaf > > > 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. > > Cheers, > Matthieu > > > > > > Assaf > > >
