linux-kernel - Re: If you want me to quit I will quit

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: <481379BB.5050208@s5r6.in-berlin.de>
Date:	Sat, 26 Apr 2008 20:51:39 +0200
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Harvey Harrison <harvey.harrison@...il.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: If you want me to quit I will quit

Linus Torvalds wrote:
> But it's not a hard rule. Sometimes simple cleanliness means that you can 
> decide to go "oops, that was *really* wrong, let's just throw that away 
> and do a whole new set of patches". But it should be something rare - not 
> normal coding practice.

Well, the need to amend single patches --- and folding the amendment in 
before mainline submission to correct important problems of the first 
shot --- is something which happens all the time.

(People will have different opinions about what is important enough to 
redo a patch instead of keeping the amendment separate.)

> Because if it becomes normal coding practice, now people cannot work with 
> you sanely any more (ie some random person pulls your tree for testing, 
> and then I pull it at some other time, and the tester reports a problem, 
> but now the commits he is talking about don't actually even exist in my 
> tree any more, and it's all really messy!).

In my experience, the submission branch cannot practically be the same 
as the development branch (I mean, a true ancestor of the of the 
development branch).  That's simply because the order of submission is 
different.

The only way to keep commits from the development branch identical in 
the submission branch would be to work with a huge number of topic 
branches, with the number of branches approaching the number of commits. 
But then testers and developers would still work with merge commits 
which will not appear in the mainline submission.  And there would be 
weird histories because of the need to merge from other trees, notably 
from torvalds/linux-2.6.git when necessary to avoid conflicts.

(I for one rebuild the development branch of linux1394-2.6.git from 
scratch after 2.6.x-rc1 came out, then keep its history until 2.6.x. 
During that time I occasionally 'pollute' it with reverts and with 
merges from torvalds/linux-2.6.git.  These will not be carried over into 
the submission branch.)
-- 
Stefan Richter
-=====-==--- -=-- ==-=-
http://arcgraph.de/sr/
--
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/