[petsc-dev] plans for PETSc release

[Satish Balay]

On Sun, 24 Apr 2016, Jed Brown wrote:

> Satish Balay <balay at mcs.anl.gov> 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