[petsc-dev] plans for PETSc release

[Karl Rupp]

Hi,

I'm not Jed, so apologies for adding my two cents on this...

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

If that is a concern, one could still fork a branch off master, which 
gets stabilized for a week and merged to maint once the release is out. 
The price to pay is the extra backporting to master, which is just as 
much a nuisance as a feature freeze.

On the other hand, a feature freeze for a week is a perfect opportunity 
for improving documentation and other work that will not break the code. 
And even if one prefers to keep coding, new features can still be put in 
next for testing. Particularly if communicated in advance ("Hey, we will 
have a feature freeze in 7 days and plan to release in 10 days"), people 
can easily arrange things. I think Lisandro's feature would have been 
ready on time if he had known 7 days in advance.

Another thing we might want to discuss at a later point is whether we 
want to rethink our release intervals and aim for ~6 months instead of 
~12 months. If we put some efforts into automating most of deployment, 
we can do this without the tedious manual work Satish has to go through.


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

Even if it's only two, it's better than zero. Providing the possibility 
for users to test (e.g. against their own set of nightly tests) is 
better than not providing the option at all.


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

I agree that a release should become a painless procedure and be mostly 
automated.


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

Thanks.


> You are being a bit pedantically Roscoe in this thread.

;-) Jed is not proposing something that induces more effort, just a more 
coordinated plan of moving things when and where.

Best regards,
Karli




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