[petsc-dev] plans for PETSc release

[Barry Smith]

  Jed,

1)   I don't think having a feature freeze in master for a week is tenable at all. Developers want to move stuff along into it and continue work as they should. Plus developers don't like to think that stuff they are working and just finishing won't be in a release for another year so will lobby (as Lisandro did) to slip into the current release.

2)   You seem to think that if we announce a freeze on master (or some branch) dozens of disparate types of users will jump all over it and do massive testing during that week finding all kinds of issues. Maybe that happens with some package's users but not PETSc; we're lucky if one or two people give it a half-hearted try out.

   This is why I think having a quick turn around time in preparing a release is best; so long as all nightly's run clean then I think we should "pop out" a release as quickly as possible on that. 

  Your concern about breaking maint is admirable, next time we could use a different temporary branch name for this beast to prevent confusion.

   Barry

You are being a bit pedantically Roscoe in this thread.


  
> On Apr 24, 2016, at 12:51 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> 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?
> 
> 
>