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
