If we don't change anything, everything will remain the same. EdB
On Sunday, October 13, 2013, Justin Mclean wrote: > Hi, > > > MORE releases means LESS work? > Yes 4.9 has a huge effort because we left it so long, it we had had a few > releases along the way the total effort would of been less IMO. The longer > we leave it between releases the more work it takes (it's not linear) and > the less likely someone will take on the role. Frankly it's a thankless > task, a large amount of effort and this is probably the last time I'll do > it. > > > As several people indicated, we'd like to help out with releases. > All anyone can do is help out how they can - no issues there. > > > I don't mind "switching" the build and Mustella jobs. > And if you're not available what happens then? > > > On your second point: you are not trying to get another SVN vs. git > > discussion going, are you ;-) > No :-) The same applies if we using git or SVN, trunk/master is basically > useless, but as I said that not really the issue, it's just currently an > extra unnecessary task for the release manager to do. > > > If that's the time it takes to do it right, than that's the time it > takes. > And again no problem with that. However most people would only be able to > put in a limited block of time as release manger. If it went on for more > than a month their situation may change and they may no longer have time to > do the role and that's probably not a good position for the project to be > in. Trying and keep the process shorter would be better because of that > IMO. There's always the next release to improve on the last. > > The develop branch should be in a reasonably usable sate at any point, > committers and PMC members should be reviewing each check in and trying out > the nightly builds when they can. There really shouldn't be a lot of work > in making a release. There's going to be some stuff that slips though the > cracks sometimes, but that's why you make frequent releases. Not everyone > is forced to upgrade and continual gradual improvements/frequent releases > attract adoption/use and hopefully new committers. Less work for everyone. > > Not everyone is going to be able to help with every release and again > that's OK. If a release candidate doesn't get the 3 +1 votes it's not a > release end of story. > > > we can set up a separate VM (as Fred suggests) > A separate VM could help out here but it's yet more infrastructure. I > prefer if we can get by with less infrastructure and process if possible. > > > Well, this all started because RC1 was cut while there were tests > failing. > Last minute checkins caused other failures which turned out to be issues > with the tests (as far as I can see but it's possible there's a minor issue > there). People seem to be getting inconsistent results with the tests which > is not helpful. > > > Lastly, I'd like to +1 on the suggestion from Alex that we wait until > > we have active positive feedback - not a LAZY consensus - from the > > active committers before we cut an RC. > That would be preferable I think, but I have to say this release candidate > is not unexpected if you look at recent checkins, JIRA and dev emails. > > > Iwe don't have marketing deadlines nor do we have impatient customers. > We do have impatient users who want bugs fixed and new releases. ;-) > > > We should release when we're ready to release, no later, but certainly > not sooner. > We release when a release candidate gets at least 3 +1 votes (and more +1 > than -1), as specified by Apache rules. > > Thanks, > Justin > > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
