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]

Message-Id: <1256657956.26028.408.camel@gandalf.stny.rr.com>
Date:	Tue, 27 Oct 2009 11:39:16 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Sam Ravnborg <sam@...nborg.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>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [RFC] to rebase or not to rebase on linux-next

On Tue, 2009-10-27 at 08:59 +0100, Ingo Molnar wrote:

> For any reasonably complex change you simply need to wait a bit anyway 
> to gather feedback. And for trivial/obvious/small patches it makes 
> little sense to upset the Git history just to add the tags.
> 
> (And if there's frequent problems with small changes that were supposed 
> to be easy you need to revisit the quality process.)

Sure, but I'm not talking about changing the patch, I'm talking about a
late "reviewed by" or "tested-by". These usually do come after a patch
set has been moved into the final git push. It would be nice to flag a
commit that it was tested by someone.

If we have to change the commit to add tested-by, then it changes the
SHA1, and if you're going to change the commit, you may be tempted to
make a small fix somewhere too. And that small fix might have an
unexpected result and nullifies the "tested-by".

Sure you can say, "don't do that" but its human nature. Someone will,
and when this patch is proven to break something, it will be
embarrassing to the tester who put their name on it.

> 
> So no, the rewinding of published for-pull git trees are not fine in 
> Linux. It's OK to post a declaredly RFC git tree with some 
> to-be-reworked patches in it - but it's not OK to publish a git tree for 
> pull and rebase it after that. You'll certainly see me complain if you 
> do that (and Linus will complain to me if i do that).

I agree with this to. And for complex changes, I usually do a RFC post
first.  But after comments and we get a good commit going, then I
sometimes get "tested-by" after the final version has been posted.
Because they tested that version.

My suggestion is to add an "annotation" commit that can tag another
commit with something like a "tested-by". This way a tester can say,
they tested this particular commit, and if someone changes it, the SHA1
will no longer match. And then we can also have a record of what commit
was tested by who, after the fact that it went into git.

A tester could have a git tree that you could pull from that only adds
annotations of what they tested. This would add to git a history of what
changes were tested by who.

Just my $0.02.

-- Steve

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