On Sun, 24 Apr 2016, Jed Brown wrote: > Satish Balay <[email protected]> writes: > > > On Sun, 24 Apr 2016, Jed Brown wrote: > > > >> Satish Balay <[email protected]> writes: > >> > >> > Master currently doesn't work as you describe. > >> > >> Why doesn't it work that way? That was the philosophy when we adopted > >> this branching model years ago, it works reliably for many other > >> projects, and I thought it worked for us when we used it that way. Did > >> something change? > > > > I was thinking about the number of times master was broken in the last > > month. > > That's a workflow problem independent of releasing. But if you feel > like 'master' is not stable enough for the promise we try to make about > 'master', putting that instability in 'maint' is pretty much the most > reckless thing possible.
You are infering something I did not say. I did not merge instable stuff into maint. > The reason for a feature freeze on 'master' is > to bring its stability up to that of 'maint'. I don't think thats enforceable. As it turns out - its not even enforceable on maint - as this thread demonstrates. > > >> > To me - currently we are at RC [yeah - witout a change in > >> > petscversion.h or a tag] - and RC to RELEASE should be via maint > >> > workflow - hence this update to maint. > >> > >> Why should RC to release "be via maint workflow"? > > > > The thought is - one you want a release in the next few days - if a > > fix is critical then it should go in. If a fix can't be in 3.7.1 then > > it shouldn't go in. And if a fix can be in 3.7.1 - then mostlikely it > > can wait till 3.7.1. > > Presumably at least one of those is supposed to be 3.7.0. But since you > haven't tagged v3.7, you're basically making 'maint' the new 'master', > which doesn't make any sense to me. I'm not making 'maint' the new master. I'm enforcing bugfix only policy. which is a maint policy. > > Anyway, if we allow 3.7.0 to ship with no more stability than a first > RC, Again you are misinterpreting my statement. I see you are interpreting" RC=>buggy - so RC should never be in maint". To me its equivalent of saying "3.6.3 is buggy - so it should have never be released - so only 3.6.4 shold have been released as 3.6" > we're basically telling users they shouldn't even bother trying > until *.*.1 releases. I think that's a cop out. Having a feature > freeze, clearing out 'next', and encouraging users to test 'master' is a > good way to make sure the *.*.0 releases are better. Barry made an anouncement on encouraging users to test a few weeks back. I don't think that works.. We are attempting to release what we know is stable. > > [there have been requests for TC testing - I was hoping we could be in > > this RC mode for a week - like a patch release test mode] > > TC? RC > > I think we should have a week of feature freeze (no new features to > 'master' or 'next') prior to tagging a release. But tag the release on > 'master'. > > >> I'd also argue we're clearly not at RC because new features (currently > >> in 'next') are still being merged. > > > > I was trying to avoid that. > > Well, there were several feature branches in 'next' before you > fast-forwarded 'maint' so it's not all a surprise. > > >> After changing 'maint', you still > >> advised Lisandro to merge new features to 'next' so that they could > >> later graduate for the release. > > > > If they can go into 3.7.1 - then they should be merged by then. [We've > > added new features in patch releases before - if they didn't modify > > exisiting API]. > > Normally the new features are more minor than a TS overhaul, but it can > be done. > > >> As for pending merges, what is the status of these branches (in 'next', > >> but not yet in 'master')? > > [...] > > > The same 'maint' criteria. If they can't go into a patch release - > > they shouldn't be merged to maint. If they can - then they can be > > merged [if they can be tested in maint again - or wait for next patch > > release] > > Normally we rewind 'next' when making a release. These features either > need to be merged or are abandoned for now (can try again for 3.8). If > they are 'maint'-eligible, then they should be merged for 3.7. Cleaning > up those loose ends is one of the things supposed to happen during the > freeze. You can formulate all this stuff now. We never had a proper freeze policy. I was attempting that. Satish > > I was trying to avoid this last minuite push to merge features - just > > before the release. > > Of course, which is why I prefer a feature freeze of about a week before > tagging a release. > > > Barry can override me on this - [If have to spin a tarball on monday] > > I won't merge anything into maint - unless they are tested fixes. And > > deferer other valid things to patch1 > > I know that when target dates slip, it's annoying and tempting to just > declare good enough. But why not spin an RC on Monday and tag the > release later in the week?
