Re: Time to flush developer accumulated patches?

"Marco Costalba" [off-list ref] 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.