[petsc-dev] plans for PETSc release

[Barry Smith]

> On Apr 24, 2016, at 1:48 PM, Karl Rupp <rupp at iue.tuwien.ac.at> wrote:
> 
> 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.

  Why, all you do is merge this "maint" branch to master every time you fix something in it.
> 
> 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.

   Nonsense, he knew weeks ahead.
> 
> 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.

   The option is ALWAYS there. We even have users who run Jenkins or buildbot against master everyday. It's not like there was not a warning that a release was coming out soon. People who want to do the pretesting (and there are very very few of them) had the opportunity. 

   Some people like to have a pre-annouced day for a release (thinking if people are told that day, they will actually finish their feature on time or do some testing before then), I've avoided this because we are reliant on people (both in and outside PETSc) whose schedules are erratic, I think people do crappy work with fixed deadlines, and when we've tried it in the past we've always pushed past it anyways so what meaning did it have?

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

   It actually is (though like anything could be made even more so), the difficulty is weighing exactly when to "pop it out" (should we wait for Lisandro's cool code, should we add this other tiny feature/fix, .....).
> 
> 
>>   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.

   Actually he is proposing something that induces more effort. For example for a whole freaking week my work-flow of moving stuff that passes the tests in next into master is broken and this induces later more manual merges because other developers started their features/fixes with outdated code. Plus I am suppose to be running around for a week fixing documentation and testing on odd-ball machines. 

   If you have a staff of programmers sitting in an office everyday whose schedule revolves completely around a software package they work on full time on the boss can say to them "ok, next week you will be doing testing stop all development". But we are not a staff of programmers sitting in an office whose schedule revolves completely around a software package they work full time, nor do we have a boss. Matt may be in China that week, Jed climbing the Matterhorn, Lisandro working on some cool new feature of PetIAG, Barry pandering to some third rate project we have to interact with for DOE politics, Emil proving some great global error estimator, Karl having another baby. The idea that there can be this magical week for the testing process where more than one PETSc person is able to exert serious effort on is absurd. What Jed proposes* is idealistic, not practical, and would result in just having a less productive week (this is why I compared it to Ross's blathering).



* a week feature freeze in master.
> 
> 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?
>>> 
>>> 
>>> 
>> 
>