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

[Paul Mackerras]

Ingo Molnar writes:

> * Paul Mackerras <paulus@xxxxxxxxx> wrote:

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

Well, I don't see a lot of build breakages in Linus' tree, in fact.

What goes into Linus' tree is supposed to have been tested by
subsystem maintainers first, and if there is stuff that goes across
several architectures, it should have been posted to linux-arch
first.  In other words, with Linus' tree the focus is on filtering out
at least the more obvious problems before they get into Linus' tree.
Sometimes that doesn't work, and then we yell at the person
responsible for a bit and then move on.

On the other hand, subsystem and architecture maintainers (such as
yourself) should be doing a reasonable amount of testing before
committing patches to any non-rebasing branch.  Some maintainers use
quilt for this, others use testing branches that explicitly get
reconstructed frequently and are not for others to build on.

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

Yet I see you pulling patches out of tip quite frequently.  When I
update my local copy of your tip/perfcounters branches, maybe one time
in three I see a forced update of at least one of those branches.

You don't seem to have separate testing and non-rebasing branches.
Instead you seem to treat the more recent commits as testing and the
older ones as non-rebasing.  I would suggest that that way of
operating isn't as clear and predictable for your downstream users as
it would be if you used separate branches.

> 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 don't follow the networking tree, but I do know that DaveM doesn't
publish commits until a reasonable period of time has passed since
committed them and he has done some basic testing of them.

Your way seems to be to push commits into tip very quickly and publish
them, and then do testing, then revert recent commits if they cause
problems.

> 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 think that's an excellent idea.  If you want to let people help you
with the testing you could also publish the commits you're testing on
a testing branch.  I would also advise a minimum latency for patches
to move from testing to the cast-in-stone branch of (say) one day
unless there is a very good reason for pushing them out more quickly.
If you have separate branches then it's clear to downstream users that
they should base their work on your cast-in-stone branch not your
testing branch.

I assume your "reasonable testing" includes building at least one
powerpc config, since you found the breakage on powerpc yourself.

> 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 be honest, I didn't think I was asking for a rebase of something
which was already cast in stone, since I didn't think you would have
cast a commit in stone before doing a build test on powerpc.

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