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?

> 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"?

I'd also argue we're clearly not at RC because new features (currently
in 'next') are still being merged.  After changing 'maint', you still
advised Lisandro to merge new features to 'next' so that they could
later graduate for the release.  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

Attachment: signature.asc
Description: PGP signature

Reply via email to