[petsc-dev] plans for PETSc release

[Karl Rupp]

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

Still something that requires extra effort and may (even though 
unlikely) lead to merge conflicts.


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

Urgency and deadlines are something people tend to consider in their 
priority queue to schedule their work. I'm merely suggesting that a 
better communicated release schedule allows us to provide a better 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.
>>
>> 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?

A feature freeze will not magically fix things if we've done a crappy 
job in the months before the release. However, each bug fixed in a 
feature freeze stage will help avoid repeated support requests later 
(some users only update between major releases).



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

The feature freeze is not meant to be enforced on everybody (i.e. 
writing documentation, testing on funky machines, etc.), but serves as a 
coordinated and agreed-upon synchronization point, where the end result 
is the best software package we could come up with. There are some 
machine configurations I can test if a release is imminent, but are not 
available for testing on a regular basis for various reasons. When 
should I run those tests if not right before the release (maximizing 
relevance)?

Best regards,
Karli