Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752099AbZJWUyT (ORCPT ); Fri, 23 Oct 2009 16:54:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751973AbZJWUyS (ORCPT ); Fri, 23 Oct 2009 16:54:18 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:47040 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751604AbZJWUyR (ORCPT ); Fri, 23 Oct 2009 16:54:17 -0400 Date: Fri, 23 Oct 2009 22:54:00 +0200 From: Ingo Molnar To: Steven Rostedt Cc: LKML , Nicolas Pitre , "Luck, Tony" , Stephen Rothwell , "Luis R. Rodriguez" , Jeff Garzik , Robert Richter , Dmitry Torokhov , Jean Delvare , Linus Torvalds Subject: Re: [RFC] to rebase or not to rebase on linux-next Message-ID: <20091023205400.GA8356@elte.hu> References: <20091022122042.e535d43c.sfr@canb.auug.org.au> <20091023112732.GB5886@elte.hu> <4AE19A74.1090709@garzik.org> <20091023123555.GA25366@elte.hu> <57C9024A16AD2D4C97DC78E552063EA3E33D0174@orsmsx505.amr.corp.intel.com> <20091023134115.GD27097@elte.hu> <20091023191631.GA1879@elte.hu> <1256326512.26028.34.camel@gandalf.stny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1256326512.26028.34.camel@gandalf.stny.rr.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=none autolearn=no SpamAssassin version=3.2.5 _SUMMARY_ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1440 Lines: 33 * Steven Rostedt wrote: > Here's the basic gist, some people believe that linux-next is used as > a dumping ground for their repos that get rebased all the time. They > use linux-next for early testing, and mostly to make sure their repo > will not collide with other developers repos. I see signs of such an attitude, and i think it's somewhat harmful. As far as using linux-next for a test-and-rebase workflow - IMO maintainer trees should lead with a good example and should not push 'avoidable crap that might need rebasing' into linux-next (knowingly at least - there's enough unintentional damage) that they wouldnt push upstream to Linus to begin with. The pure act of integration testing (the stated primary purpose of linux-next) is a large enough of a job in itself IMHO. Maintainer trees pushed towards linux-next should strive to be Git based, append-mostly, 'nice', 'intended for upstream' and defendable as-is IMO, and rebasing a _maintainer tree_ should really be a rare act of last resort. [ Developers OTOH can (and will and perhaps should) rebase frequently until a feature becomes pushable. ] Anyway - just my two cents - YMMV. Ingo -- 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/