[petsc-dev] plans for PETSc release

[Satish Balay]

On Sun, 24 Apr 2016, Jed Brown wrote:

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