lkml.org 
[lkml]   [2009]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] to rebase or not to rebase on linux-next
From
Date
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




\
 
 \ /
  Last update: 2009-10-27 16:41    [W:0.771 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site