[petsc-dev] plans for PETSc release

[Jed Brown]

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.  The reason for a feature freeze on 'master' is
to bring its stability up to that of 'maint'.

>> > 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.

Anyway, if we allow 3.7.0 to ship with no more stability than a first
RC, 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.

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

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.

> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160424/bb831d7f/attachment.sig>