lkml.org 
[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Slow DOWN, please!!!
Date
On Wednesday, 30 of April 2008, Linus Torvalds wrote:
>
> On Wed, 30 Apr 2008, Linus Torvalds wrote:
> >
> > In fact, I'd personally like to make it even shorter
>
> Just to clarify: I'd actually like to make the merge window be just a
> week. If even that.
>
> With linux-next hopefully stepping up to be a place where the actual
> _conflicts_ (which are usually not the big problem, they are just
> inconvenient from a timing standpoint) can get found and handled early, a
> shorter merge window should be technically possible.

That even might be better, if there's less code merged as a result.

> HOWEVER. Even now, at two weeks, we do have issues where timing just
> doesn't fit some developer, because of conferences or vacations or just
> random personal issues or whatever. There are always people who grumble
> because the window didn't work for them.

Well, where's it stated that you have to develop new code for each merge
window? By making shorter merge windows with less code merged in each of
them, we could actaully improve things.

> Of course, they should have had it all ready, but somehow that simply
> doesn't happen. I think it's against most human nature to be quite _that_
> forward-looking.
>
> And maybe everything would be ok if we could also shorten the actual
> release cycle, so that if you miss one merge window for some random
> conference or other (or just a *really* bad hair-day and you didn't get
> your act together), you wouldn't mind too much and you'd just hit the next
> one instead.

Exactly.

> But that, in turn, is unrealistic because when bugs do happen, the latency
> you get between testers and developers is long enough that I really don't
> think we can shorten the after-merge-window thing much. Six weeks seems to
> be already pushing it.

That depends on the amount of bugs introduced during the merge window. With
shorter merge windows we may introduce fewer bugs per merge window and
the most subtle ones take more six weeks to find anyway.

> And as mentioned, a longer after-merge-window-stabilization phase is just
> going to aggravate the problem next time around.
>
> We could have staggered releases, but let's face it, that's what -mm and
> linux-next and stable is all about.

Well, that's assuming that people test linux-next and -mm etc., but frankly I'm
not seeing that happening. Hopefully, things are going to improve.

Thanks,
Rafael


\
 
 \ /
  Last update: 2008-04-30 23:01    [W:0.303 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site