On Monday, July 29, 2013 08:11:41 AM Jonathan Corbet wrote: > On Mon, 29 Jul 2013 15:10:33 +0200 > "Rafael J. Wysocki" <r...@sisk.pl> wrote: > > > That actually is simple enough. > > > > Check out the Linus' master branch and do > > > > $ git log --ancestry-path --merges <commit>.. > > So I picked a recent, single-signoff patch mostly at random: > > 8ade62857ef77bdf639185410fbcd811aa700cb2 > > That "git log" command gives me 156 intervening commits involving at least > a dozen networking trees, along with virtio, parisc, blackfin, x86, ... > Even if one stops looking at the first merge performed by Linus, that's 47 > to look at. Did that patch really pass through all those peoples' hands? > > Plus, of course, this assumes there's no fast-forward merges in the mix.
Well, let's just say that the "git describe --contains" method described by Paul (http://marc.info/?l=linux-kernel&m=137511549202238&w=4) is better and using gitk also works, as noted by Jiri (http://marc.info/?l=linux-kernel&m=137511562702289&w=4), but the point is that the information is there and the effort needed to extract it is not overwhelming. What SOBs are useful for is to track the origins of a given patch before it enters a git repository, but once that's happened, all of the history is recorded by git. > From your other message: > > > And what about trusting maintainers? If Linus trusts them enough to pull > > from > > them, why can't everybody else trust them enough to assume that they don't > > do > > bad things on purpose? > > I hope you're not reading such thoughts into what *I* wrote. No, I'm not. And in fact this last paragraph of my previous message sounds much stronger than I wanted it to. I didn't mean things like adding bad code to the kernel in a sneaky way, which in my opinion is out of the question. I meant things like making changes with the maintainer's own SOB without posting them for public review beforehand, which would be an abuse of the process even if the changes themselves were useful and correct. > But most anybody who works on code occasionally does bad things by mistake, > that's why we have a review process. Of course. But that has nothing to do with how many SOB tags there are in the given commit log. There are submitters whose patches already have a couple of them when they are first posted. A single SOB tag usually means that the committer himself is the author of the change set and I don't see why this should be regarded as a bad thing in principle. Yes, it is technically possible for maintainers to "cheat", for example by making unreviewed changes and pushing them upstream with their own SOBs even without any linux-next testing, but they can do damage in some other ways too if they are irresponsible. We generally don't record information about what mailing lists the given patch was submitted and how much time the maintainer waited for comments before applying that patch. I suppose we possibly could record it, but then I'm not sure how useful that will be in general. It definitely would mean more work for maintainers and it's not like they don't have enough of that already. Moreover, perhaps we can simply expect maintainers not to abuse the process? I guess my point is that the fact that there are commits with one SOB tag only doesn't have to mean that we have a problem of any sort and it even doesn't have to indicate the existence of such a problem. Commits that have never been in linux-next are much more problematic in my opinion. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
