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] [day] [month] [year] [list]

Message-Id: <1209409514.25791.7.camel@localhost>
Date:	Mon, 28 Apr 2008 21:05:14 +0200
From:	Romano Giannetti <romanol@...omillas.es>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Adrian Bunk <bunk@...nel.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


On Sat, 2008-04-26 at 13:35 -0700, Linus Torvalds wrote:

> > Fact is, this is the way in which developers want to work.  That is their
> > workflow, and their tools should follow their workflow.  If a tool's
> > behaviour prevents them from implementing their desired workflow, it isn't
> > the workflow which should be changed ;)
> 
> But that was exactly my point. Bugs *will* happen. Follow-up patches 
> *will* happen. Don't fight it. Do the best you can do - there's no way 
> people will ever avoid all bugs to begin with. 

Sorry if I drop in into a thread that's probably too big for me, but I
was having an idea (probably horribly wrong, but I try... don't beat too
hard). I think the main problem is when a fix to a change occurs quite
after the change went in, creating bisection problems (I've had
something like that bisecting an MMC problems some time ago). 

Wouldn't be nice to have the concept of patch series in git? Maybe the
sha1 of the first commit of the patch? Then a fix on the series can be
marked  as such, and you could teach git bisect to go first series by
series, applying/removing the fix patches as needed... and just at the
end dive into the commits. Maybe it's impossible/too complex/exponntial,
but well, it just a git git idea :-)

Romano

-- 
Sorry for the disclaimer --- ¡I cannot stop it!



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. 
--
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/