linux-kernel - Re: [GIT] Networking

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: <1300193560.9910.265.camel@gandalf.stny.rr.com>
Date:	Tue, 15 Mar 2011 08:52:40 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	david@...g.hm
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Ben Hutchings <bhutchings@...arflare.com>,
	David Miller <davem@...emloft.net>,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] Networking

On Tue, 2011-03-15 at 00:20 -0700, david@...g.hm wrote:

> > It really is meaningless to do so, as all you are doing is documenting
> > what commit caused this bug, and producing more problems by branching
> > off of the broken commit. It wont matter till it is merged, but then if
> > there are a lot of simple bug fixes, then you will have a lot of single
> > merges of branches that fix those bugs.
> 
> what effect would this have on bisecting? if this helped people avoid 
> bisecting in between the bad commit and the fix for it, it may be worth 
> it.
> 

But it wont, as the fix will still be brought in at a later time. It has
nothing to do with being based off of the broken commit.

         A  +
            +   merged in fix
         B  + \
            |  |
            |  |
            |  |
Lots of     |  |
  stuff     |  |
            |  |
            |  |
            |  + - fix for bug
            | /
 Bug commit +
            |

A bisect will still be testing lots of stuff without that fix. And if it
goes into the branch with the fix, we just brought the kernel way back
in time from point A. Then if it goes back to point B, then we zoom back
to the future and bounce the kernel all over the place.

I see no gain for having a fixed based off of the bug that it fixes.

Pros of doing this:

1) documents the point that things broke (can be done by commenting it
in the change log too)

2) probably good for back porting (but Con 3 may out weigh this)

Cons:

1) Adds many more branches and merges for no real good reason

2) Makes bisects even less linear than it already is

3) May cause more conflicts at the merge point as the broken code may
have changed.



Who will be doing the conflict resolutions? Linus? I doubt he would be
happy with that, but he can speak for himself.

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