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