linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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]

Message-Id: <20080212.161203.16478915.davem@davemloft.net>
Date:	Tue, 12 Feb 2008 16:12:03 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	linville@...driver.com
Cc:	jeff@...zik.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

From: "John W. Linville" <linville@...driver.com>
Date: Tue, 12 Feb 2008 12:04:22 -0500

> 	net-2.6.26		updates certain to go to the next release
> 	net-2.6.26-maybe	updates that might not make it to the next release

If I knew something was "maybe" ahead of time I simply would not apply
it.

Everything I apply to my tree I feel is likely to get integrated.  If
it isn't, I let the patch work itself out on the lists and amongst the
interested developers.

The real issue is deleting crap.  Once something that seemed like a
good idea turns sour I want to remove it entirely.  This isn't doable
without a rebase.

Also, and Andrew does this a lot, I want to clean up changes which
have problems I only notice later.  In fact the rebase process turns
up all kinds of things such as whitespace errors that I get when
merging other people's trees.  Having extra changesets with the
small fixups adds zero value and just more churn to go over when
reading changesets.  A small annotation to the changelog will
do, that answers the "where did this come from?".

With patches and rebasing that operation is easy, and I'm willing to
deal with all of the rebasing of subsequent changesets that is usually
caused by such things.  Yes, I'm even willing to do it to patch #1 in
a 1500 patch tree. :-)
--
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/