[petsc-dev] plans for PETSc release

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

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

He knew that a release was coming, but no particular date.

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

However, there was no guarantee that such testing would be relevant to
the release.  Someone could be working on some feature that is going
into the release.

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

You have announced specific dates in the past.  Every conference has a
deadline for paper submission and many/most extend it by a week or two.
I think there would be mass complaints if the organizers instead
announced that they were going to close submissions at some point in the
coming weeks, let some time go by, then said today's the last day for
submissions.

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

Our features are rarely so interdependent that the feature you implement
today breaks the feature some other developer starts on Tuesday.  That
merge isn't really urgent and the marginal cost of waiting a week is
really low.

But I think the reminder about fixing documentation and any outstanding
bugs/reports is well worth it in terms of improving the quality of the
release.

Not every user that encounters a bug reports it.  While the cost to us
in fixing a bug is about the same if it is discovered and fixed in
'master' versus 'maint', it is significantly higher for users.
Moreover, when we ship a release with bugs, users encounter that bug for
months, even after we have patched it (they don't instantly and
effortlessly receive the patch release when we tag it), and then we get
the support mail.  So bugs that affect multiple users are much more
costly when discovered after the release.

>    If you have a staff of programmers sitting in an office everyday

[...]

I have no expectation that everyone participate actively in the release.
But I also don't think it's true that everyone ignores the release
either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20160424/a87979dd/attachment.sig>