Re: [tip:timers/core] timekeeping: Increase granularity ofread_persistent_clock()

From: Ingo Molnar
Date: Mon Aug 24 2009 - 04:23:53 EST

* Paul Mackerras <paulus@xxxxxxxxx> wrote:

> Ingo Molnar writes:
> > Do you ask Linus to rebase the upstream kernel as well, if the
> > powerpc or x86 build happens to break? There's more than a dozen
> > such cases per development cycle triggering on my tests alone. If
> > not, why not?
> I see you pulling commits out of the tip tree quite often, when
> they have testing failures of various kinds. I presume that, like
> other maintainers, you have some branches that you try hard not to
> rebase and other testing branches that are quite volatile and get
> reconstructed frequently (though I don't know what branch names
> you use for them).
> I presumed that you wouldn't have put a commit that hadn't even
> passed basic build testing into one of your non-rebasing branches.
> That's why I assumed you could fold the fix into the original
> patch without difficulty.

Sometimes rebasing is possible, sometimes not. Here it's borderline
- the commit was already behind other commits.

> > The thing is, we'll probably redo this portion of the timer tree
> > as i found other problems in testing, but generally the
> > disadvantages of a build breakage with a very small
> > non-bisectability window has to be weighed against the
> > disadvantages of a rebase (which are significant).
> >
> > The equation does not automatically flip in favor of a rebase as
> > you seem to suggest - in fact it generally goes _against_ a
> > rebase.
> In a stable, non-rebasing branch, sure. But putting untested
> patches into such a branch would be a bit silly, so I assumed you
> hadn't done that. :)

You have not answered my primary question though AFAICS. There's
_more_ build breakages in Linus's tree (in a volume-scaled form), so
why dont you request rebases there?

If you requested them you'd have a snowball's chance in hell, Linus
has never rebased the upstream tree, ever. Once pushed out for
others to pull it's cast into stone. Yes, sometimes the build
breaks, especially on rarely used architectures. We fix them.

The more frequently an architecture is tested, the more it is used
in practice, the more a driver and an architecture matters the
shorter the bisection breakage window becomes. The upstream kernel
is a self-tuning process of quality, even without rebases and

(DaveM does something quite similar to Linus too AFAICS, he too
never rebases the networking tree.)

I'm thinking about starting to do the same for all -tip trees too: i
do reasonable testing before pushing it out, on the most common
architecture and driver selection, and once pushed out it's cast
into stone Git-wise.

I actually start regretting that i do rebases too frequently - some
people (not you really, but you gave me the perfect example to reply
to) want more and seem to think they are _entitled_ to rebases and
are entitled to backmerges. The thing is, rebases are not free. They
are risky and error-prone, and they destroy Git history.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at