From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765035AbYD3UP1 (ORCPT ); Wed, 30 Apr 2008 16:15:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756441AbYD3UPS (ORCPT ); Wed, 30 Apr 2008 16:15:18 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:49970 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbYD3UPR (ORCPT ); Wed, 30 Apr 2008 16:15:17 -0400 Date: Wed, 30 Apr 2008 13:14:39 -0700 (PDT) From: Linus Torvalds To: "Rafael J. Wysocki" cc: David Miller , linux-kernel@vger.kernel.org, Andrew Morton , Jiri Slaby Subject: Re: Slow DOWN, please!!! In-Reply-To: Message-ID: References: <20080429.190352.137408408.davem@davemloft.net> <200804302136.58005.rjw@sisk.pl> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. 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. 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. 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. Linus