"Marco Costalba" <mcostalba@xxxxxxxxx> writes:
> I understand that you want people focused on fixing bugs, but I also
> understand that people don't ;-)
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
conflicts
Bogus.
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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
