On Wed, Apr 23, 2008 at 2:57 PM, Alexis Midon <[EMAIL PROTECTED]> wrote:
> it's more about us as users than about PMC members (despite my respect ;). > Solution #1 would bring confusion I think and might piss off many users. > > And what if the PMC vote is negative? One non-apache release 1.3 would be > in > the wild, available on Rubyforge while some updates would have to be done > to > prepare a new PMC vote. > would you increment the version then? Absolutely. We'll make a fix, then repeat the process again for the new version which includes this fix. Whichever option we choose, we won't have two packages with the same version number but different content. Assaf > > I'd rather consider rubyforge as simple file server, and stick to the > apache > process. > > > > > On Wed, Apr 23, 2008 at 2:36 PM, Yoav Shapira <[EMAIL PROTECTED]> wrote: > > > On Wed, Apr 23, 2008 at 4:57 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > 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. > > > > I really think we should have the PMC vote first. Otherwise you > > unnecessarily get into gray area and might piss off some PMC members. > > Why take the unnecessary risk? > > > > Yoav > > > -- CTO, Intalio http://www.intalio.com
