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. > > > 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. [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] > > 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. > 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]. > If any of those changes affect the API, > then people on 'maint' have gotten an API that will never be released. > This breaks our promises with respect to 'maint'. The whole point of > that branch is to have something stable that users can update > worry-free. > > > I didn't intend to be rude to our 'maint' users. Ideally there should > > have been a tracking branch maint-3.6 always - so users who whish to > > time the switch from 3.6 to 3.7 do this on their terms [and not > > implicitly via maint]. > > > > I'll make an annoucement to maint users about switching to maint-3.6 > > branch. > > Okay, but I think we should never do a release this way again. We > should finish all merging to 'master', tag the release on 'master', then > fast-forward 'maint' and rewind 'next'. > > As for pending merges, what is the status of these branches (in 'next', > but not yet in 'master')? > > barry/fix-some-clang-warnings > knepley/feature-fe-nonaffine > knepley/fix-mem-init > pr329/master/Fande-Kong/matpartitioning-hierarch > pr359/master/Fande-Kong/fix-mat-convert-nest-aij > tisaac/dmp4est-feature-mapped-coordinates > tisaac/fix-ex3-coords 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] I was trying to avoid this last minuite push to merge features - just before the 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 Satish
