On Thu, May 01, 2008 at 12:07:53PM -0700, david@lang.hm wrote:
quoted text
> On Thu, 1 May 2008, Willy Tarreau wrote:
> 
> >I also proposed to group merges by reduced overlapping areas, and to
> >shorten the merge window and make it (at least) twice as often. Rafael
> >also proposed to merge core first, then archs, which is a refined variation
> >on the same principle. I'm not sure I've seen your opinion on this.
> 
> the problem with trying to make the cycle twice as fast is that it takes 
> time to hunt down the hard bugs, even when you have some idea where they 
> are.

Of course, they'll always be bugs. They'll still slip past the release,
as many are doing today.

quoted text
> go back through the last few kernels and look at the bugs that were fixed 
> in the last couple of -rc releases (and in final), would they have really 
> been fixed faster if other changes hadn't taken place?

Don't know. However, I think that core bugs have more impact on the rest
than other bugs. Reason to merge core first.

quoted text
> I suspect that they would not have, and if I'm right the result of merging 
> half as much wouldn't be twice as many releases, but rather approximatly 
> the same release schedule with more piling up for the next release.

no, this is exactly what *not* to do. Linus is right about the risk of
getting more stuff at once. If we merge less things, we *must* be able
to speed up the process. Half the patches to cross-check in half the
time should be easier than all patches in full time. The time to fix
a problem within N patches is O(N^2).

quoted text
> even individual git trees that do get a fair bit of testing (like 
> networking for example) run into odd and hard to debug problems when 
> exposed to a wider set of hardware and loads. having the networking 
> changes go in every 4 months (with 4 months worth of changes) instead of 
> every 2 months (with 2 months worth of changes) will just mean that there 
> will be more problems in this area, and since they will be more 
> concentrated in that area it will be harder to fix them all fast as the 
> same group of people are needed for all of them.

You're perfectly right and that's exactly not what I'm proposing. BTW,
having two halves will also get more of the merge job done the side of
developers, where testing is being done before submission. So in the
end, we should also get *less* regressions caused by each submission.

quoted text
> if several maintainers think that you are correct that doing a merge with 
> far fewer changes will be a lot faster, they can test this in the real 
> world by skipping one release. just send Linus a 'no changes this time' 
> instead of a pull request. If you are right the stable release will happen 
> significantly faster and they can say 'I told you so' and in the next 
> release have a fair chance of convincing other maintainers to skip a 
> release.

again, this cannot work because this would result in slowing them down,
and it's not what I'm proposing.

Willy

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/