linux-kernel - Re: [RFC] to rebase or not to rebase on linux-next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 23 Oct 2009 23:59:58 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	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

On Fri, Oct 23, 2009 at 10:54:00PM +0200, Ingo Molnar wrote:
> 
> 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.

As maintainer I try to put some effort in crediting people
where credit belongs.
In other words collecting "Acked-by:", "Tested-by", "Reviewed-by".

Adding this require a rebase as soon as said patch hits git.

One could use topic brances and I do not know what.
But frankly - working with this on and off and
in limited spare time makes it sometimes hard enough
to do the basic steps correct.
Trying to fool around with several topics branches and
such does simply not fit.

I try to say with the above that rebasing is sometimes 
a way to get the job done without making things too complicated.

And -next has btw caught a lot of integration issues
for kbuild in the past.
Both for varoious architectures but sometimes also
other ways to do the same thing.
And sometimes I'm in the situation that I have to decide:

1) wait another 10 days before I have ~1 hour that I can
dedicate to test stuff
2) do some rudimentary testing and drop in in -next.

It depends but sometimes I go for option 2) knowing
that it is risky.

	Sam
--
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/