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
