On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> That being said, you should also consider (unless somebody forgot to
> tell me something) that it takes two source trees to make a split-out
> patch. The author also has to chew down everything but the feature he
> wants to split out. I could probably log 10,000 man-hours splitting up
> GrSecurity. :)
I'd try out Andrew's patch scripts if I were you. If you're making a patch to
the kernel, you'd best keep it in separate patches from the beginning, and
that's exactly what those scripts are very useful for.
> > It's also a lot easier to find the (inevitable) bugs. Either you already
> > have a clue ("try reverting that one patch") or you can do things like
> > binary searching. The bugs introduced a patch often have very little to do
> > with the thing a patch fixes - exactly because the patch _fixes_
> > something, it's been tested with that particular problem, and the new
> > problem it introduces is usually orthogonal.
>
> true. Very very true.
>
> With things like Gr, there's like a million features. Normally the
> first step I take is "Disable it all". If it still breaks, THEN THERE'S
> A PROBLEM. If it works, then the binary searching begins.
So how do you think you would do a binary search within big patches, if it
would take you 10,000 man-hours to split up the patch? Disabling a lot of
small patches is easy, disabling a part of a big one takes a lot more work.
> > Which is why lots of small patches usually have _different_ bug behaviour
> > than the patch they fix. To go back to the A+B fix: the bug they fix may
> > be fixed only by the _combination_ of the patch, but the bug they cause is
> > often an artifact of _one_ of the patches.
> >
>
> Wasn't talking about bugfixes, see above.
Oh, so you're saying that security fixes don't cause bugs? Great world you live
in, then...
> > IOW, splitting the patches up makes them
> > - easier to merge
> > - easier to verify
> > - easier to debug
> >
> > and combining them has _zero_ advantages (whatever bug the combined patch
> > fix _will_ be fixed by the series of individual patches too - even if the
> > splitting was buggy in some respect, you are pretty much guaranteed of
> > this, since the bug you were trying to fix is the _one_ thing you are
> > really testing for).
>
> Lots of work to split up a patch though.
See above.
Sytse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
