Current policy during rc stabilization period is roughly:
- No new feature is accepted, starting early in the rc cycle;
- An intrusive fix is sent back and requested to be rewritten
as minimum "fix" without enhancements, starting mid rc cycle;
- I do not want to take patches early.
The third point is a double-edged sword:
- Developers can easily get distracted when encouraged to do
new things. That's human nature. Everybody finds doing new
things more interesting than finding and fixing existing
bugs.
This is especially true if the fix is about somebody else's
code and the breakage does not affect you. Even your own
earlier half-baked-hack that has not been discovered by other
people is often not interesting to fix (once discovered, the
embarrassment factor tends to make it a higher priority).
However, we won't have enough good people who know the
codebase and are capable of fixing existing bugs if they all
go and work on "other" things.
- Developers tend to notice _existing_ breakage more easily
when given a chance to play with _existing_ code (either
enhancing the existing code, or adding new call sites to the
existing API). And one way to encourage playing with
_existing_ code is to to encourage developing on top of it.
In earlier releases, I used to keep 'next' open during the freeze. I think it had the effect of encouraging new things too much without having enough side-effect (from the point of view of a person who wants to do new things) of uncovering and fixing existing issues (which is the primarily desired effect during the stabilization).
This time I have been deliberately playing differently to strike
the balance a bit differently:
- In order to discourage new things, I do not accept patches
early.
- In order not to discourage new things too much, I try to give
brief feedback, and add them to "What's not in 'master', and
likely not to be until 1.5.4".
Another practical reason I do not take patches early is because it is a time drain. Taking patches early means it will increase the merge impact _before_ 1.5.4.
Now that high level description out of the way, let's see what you said:
- Give more time to fix bugs before 1.5.4 is out without stopping
people from having fun and reduce the pressure to release.That is precisely what I want to discourage.
- Reduce the merging impact when master reopens because patches are
already merged in new_stuff and developers have already taken care of
conflictsBogus.
When two or more new things are outstanding, and if I take patches early, 'next' needs merge resolution. You are arguing to take my time away from what matters to 1.5.4 during the stabilization period, and instead encourage people to have fun and get distracted.
Post 1.5.4 if one series contradicts/conflicts with another, I can just say "I have decided to take that series and your series conflicts with it. Please rebase", to shift the burden to the contributor of the second series. If I do that before 1.5.4, that means I will not just encourage but actively ask the second contributor not to work on uncovering and fixing existing issues but spend time on new things.
Do you think that helps the stabilization period in _any_ way?
- Do not slow down the wheel: I can develop some patches and keep them
myself, but until are not discussed in the list and eventually got in
master has little meaning to continue develop additional stuff.That's exactly the point of stabilization freeze. You can develop and keep developing. I have a few topics myself that are backburnered, and I occasionally visit them when I am bored. However, I try not to distract others with the series. Please try to do the same.
