[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091023205400.GA8356@elte.hu>
Date: Fri, 23 Oct 2009 22:54:00 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Nicolas Pitre <nico@...xnic.net>,
"Luck, Tony" <tony.luck@...el.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"Luis R. Rodriguez" <mcgrof@...il.com>,
Jeff Garzik <jeff@...zik.org>,
Robert Richter <robert.richter@....com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jean Delvare <khali@...ux-fr.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] to rebase or not to rebase on linux-next
* Steven Rostedt <rostedt@...dmis.org> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists