| 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