On Thursday, August 01, 2013 12:16:40 PM Geert Uytterhoeven wrote: > On Tue, Jul 30, 2013 at 12:09 AM, Rafael J. Wysocki <r...@sisk.pl> wrote: > > 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. > > And we still have (too many of) them... > > Once in a while, I do find suspicious commits that > (a) weren't in -next, > (b) weren't in my email archive (not unreasonable, as I'm not > subscribed to all > Linux mailing lists ;-), > (c) are not to be found by Google, which means they may not have been > posted for public review at all (are there Linux mailing lists that do > not > have a web archive?).
I wonder if it's feasible to publish a list of such commits once in a while? It doesn't have to be complete, I guess. Rafael -- 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/
