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

[Ingo Molnar]

* 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 
backmerges.

(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.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/