Pre-branch commits

[Robert Elz <kre%munnari.OZ.AU@localhost>]

  | Anyway, what was the urgency?  Were you somehow under
  | the impression that the branch was taking place last weekend
  | and you had to rush these

This message is not a comment (in any way) on the substance
of the issue being discussed in the quote above, or about the code
involved, or the motives of any concerned developers, but about the
more general problem.    (Hence I have removed all attributions from
this message, though I know they would not be hard to track.)

There is a problem we need to deal with ... if releng announces
"the branch for netbsd-XX will happen on Foomonth the 57th",
then in the few days leading up to that date, lots of developers
commit their not-really-ready code to HEAD, so that it will be in
the branch, and then can be fixed via pullups later (which then
is likely to increase the preiod between branch and release
while everything that needs fixing gets fixed and the release
waits on that one last thing.)

To avoid that problem, we have the current situation, where there
is no such announcement, but the branch simply happens with
no warning .... except that everyone knows it is coming "soon".
Then developers rush to commit whatever they have, asap, to
make sure their new code is in the branch, and then it can be
fixed later, and if that happens after the branch has occurred, 
pullups are requested,   Nothing has changed except we get even
worse code (less tested, less reviewed) being commmitted to HEAD
because of the uncertainty.

I'd like to suggest a possible solution:   Go back to the old way,
and announce the branch date in advance (with a reasonable
lead time, not just a day or so, which would change nothing.
Reasonable here is likely to be something like a month.)

Then developers have plenty of advance warning, and can
finish their code properly, get it reviewed (as needed) and
properly tested.

For the cases where there still was not enough time, and code
that is not really ready gets committed, and then there's an
attempt to fix it later, the policy should be that on the branch,
any changes made between the pre-announcement of the
branch date, and the actual branch, which later need corrections
will not be corrected on the branch, instead the change which
occurred in that period will be reverted on the branch.

Of course, exceptions can be made for changes that are
really needed, or where an update is required because of
something unforseeable (ie: the change commit seemed to
be correct, and tested, but some later event, or unrelated
change, requires alterations).    Both of those should be
rare - if there are "really needed" changes, the branch
date should normally not have beeen announced until they
are done (that's the "we need ABC in the next release" kind
of thing, and ABC isn't yet finished, and the unforseeable type
will simply be rare by its nature.

kre