Prev: [PATCH] vmscan: zone_reclaim don't call disable_swap_token()
Next: Btrfs: broken file system design
From: Ingo Molnar on 25 Jun 2010 04:50

* Andrew Morton <akpm(a)linux-foundation.org> wrote:

> On Thu, 24 Jun 2010 21:27:13 -0700 (PDT) David Miller <davem(a)davemloft.net> wrote:
>
> > From: Andrew Morton <akpm(a)linux-foundation.org>
> > Date: Thu, 24 Jun 2010 20:50:59 -0700
> >
> > > What happens if you want to actually *drop* a patch from net-next?
> > > Surely that happens?
> >
> > I've only respun the tree on two or three occasions and that was
> > because I made some significant error myself and screwed up the
> > GIT tree somehow.
> >
> > We've fixed much worse bugs than this one weeks after the changes
> > causing them went in, life goes on.
>
> Still sucks - this is a quite ugly drawback to how we're using git.
> I've hit bisection holes several times which held up the show.
> Sometimes you can make them go away by fiddling the .config, other
> times I've hunted down the fix and manually applied it for each
> iteration. It makes me feel all guilty each time I ask some poor sap
> to bisect a bug for us.

One solution would be, for really grave bugs that introduce a significant
window of bisection breakage, to add a special tag:

Fixes-Bug: SHA1

Which could then be parsed by a special variant of git bisect and which would
try to cherry-pick all Fixes-Bug commits into the bisection point.

But there are numerous disadvantages that:

- The bisection itself would be slower (maybe not a big issue for most
bisection sessions)

- Such cherry-picked trees wouldnt be precisely the same thing as the tree
as-it-was-there.

- Awkward combination bugs could ensue

- The cherry-pick may fail or may mis-apply things.

- If the Fixes-Bug tag is typoed or misconstrued then that might not be found
until someone tries a bisection and fails ... leading to awkward
add-the-tag-again-to-some-commit scenarios.

My gut feeling is that we really dont want to go there. As painful as
bisection breakages are, they are relatively rare (compared to regular
regressions), and the value of testing _that precise_ sha1 is a fundamental
thing - git bisect shouldnt interact and reorder fixes.

If a bug wasnt found sooner then it either didnt matter that much, or the tree
QA was bad. Neither of those factors forces a change in the development model.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] vmscan: zone_reclaim don't call disable_swap_token()
Next: Btrfs: broken file system design