Erik, Did you setup an external address for Jenkins or I need to log on your VM in order to see how you configured the builds ? I want to setup my VM to run some of them or at least the RCs based on what you did.
Thanks, -Fred -----Message d'origine----- De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : dimanche 13 octobre 2013 15:18 À : dev@flex.apache.org Objet : Re: Mustella tests failing and release candidates 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
