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:	Sat, 13 Jul 2013 08:44:30 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Theodore Ts'o <tytso@....edu>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"John W. Linville" <linville@...driver.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable <stable@...r.kernel.org>,
	ksummit-2013-discuss@...ts.linux-foundation.org
Subject: Re: [Ksummit-2013-discuss] When to push bug fixes to mainline


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, Jul 12, 2013 at 11:28 AM, H. Peter Anvin <hpa@...or.com> wrote:
> >
> > OK, just read up some more on git notes, and *both* the assumptions I 
> > had made about git notes were fundamentally wrong.  Not sure how well 
> > they would scale, though, but stuffing metadata like additional 
> > Acked-by:, Tested-by: and Cc: stable into notes seems more viable 
> > after reading the spec.
> 
> I really don't want to use git notes for anything that actually gets 
> distributed.

Regardless of any scalability and other technical merits, allowing tags to 
go into a commit log entry via git notes would IMO dilute the value of 
Acked-by and Reviewed-by tags and it would actively hurt our kernel 
development workflow I think.

Today there's a time limit on acking/reviewing patches: if it did not 
arrive by the time the code was committed and pushed out, it does not get 
into the commit log, ever. That gives people an incentive to be active 
_before_ a patch gets applied.

And that's really how it should work IMO: the most important, most 
critical decision point is when a patch gets applied to a tree with the 
intent to send it upstream. Maintainers need the most help at that point. 
Anything after that, unless it points out actual problems or room for 
improvements (which will generate new commits), is not very useful.

So adding git notes after that point to add Acked-by or Reviewed-by tags 
is just post facto whitewashing, ego stroking or pointless act 
self-serving bureaucracy, beyond being a sign of a broken Git workflow to 
begin with.

Thanks,

	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

Powered by Openwall GNU/*/Linux Powered by OpenVZ