* 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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|