Dear Scott Wood,
In message 1349980244.6903.13@snotra you wrote:
The number of people working on next should be small and manageable.
More people likely use next than some custodian branches, and those are supposed to be rebase-free...
Wouldn't anyone developing code for the next merge window be working on next, at least when it's not out of date?
Yes. And we do not rebase next lightly nor often (just check this history how often this happened in the past). But we explicitly reserve the right of doing this to make sure we get the needed quality of the code before pulling it into master, which definitely cannot be rebased. So instead of knowingly pulling blatant crap into master we will rather make this exception and rebase next.
IMHO it would be nice for the next branch to open immediately after the merge window closes, and be kept up to date except during the merge window. Historically the next branch has opened when someone requests a pull into it, but how do I make a sane pull request when the next branch has been untouched since the last release?
No. Historically next was opened when -rc1 was released. In theory this would be at the end of the MW, but I always found myself with a large backlog of patches tat were not picked up by any custodian trees but left waiting, and I wanted to have these included in the -rc1, which reasulted in the often week-long delay.
Provide more people processing patches, say pushing stuff through the staging repo etc., and we can easily reduce this delay.
Best regards,
Wolfgang Denk