* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process [not found] ` <alpine.LNX.2.00.1307291230270.18809@pobox.suse.cz> @ 2013-07-29 13:10 ` Rafael J. Wysocki 2013-07-29 14:11 ` Jonathan Corbet 0 siblings, 1 reply; 14+ messages in thread From: Rafael J. Wysocki @ 2013-07-29 13:10 UTC (permalink / raw) To: Jiri Kosina, Samuel Ortiz; +Cc: ksummit-2013-discuss, LKML On Monday, July 29, 2013 12:31:37 PM Jiri Kosina wrote: > On Mon, 29 Jul 2013, Samuel Ortiz wrote: > > > - Developement process: Jon Corbet's article about our changelog raised > > one interesting question: How can we better track how single SOB > > patches are getting merged ? That actually is simple enough. Check out the Linus' master branch and do $ git log --ancestry-path --merges <commit>.. and read the log from the bottom to the top. > > Should maintainers add their SOB when > > they pull from subsystems maintainers (If they can) ? This is > > something I care about from both my MFD and NFC maintainer > > perspectives as I both pull from MFD sub maintainers and am John > > Linville's NFC sub maintainer. > > This is difficult ... I think that in some sense merging from subsystem > maintainer tree can be viewed as an "implicit" Signoff, although this > hasn't been formalized anywhere. > > I am afraid there is no way git could handle this easily without rebasing. No, there's none, as you'll always change the commit hash by adding tags to it. Thanks, Rafael ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 13:10 ` [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process Rafael J. Wysocki @ 2013-07-29 14:11 ` Jonathan Corbet 2013-07-29 16:31 ` Paul Gortmaker 2013-07-29 22:09 ` Rafael J. Wysocki 0 siblings, 2 replies; 14+ messages in thread From: Jonathan Corbet @ 2013-07-29 14:11 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Jiri Kosina, Samuel Ortiz, ksummit-2013-discuss, LKML On Mon, 29 Jul 2013 15:10:33 +0200 "Rafael J. Wysocki" <rjw@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. >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. But most anybody who works on code occasionally does bad things by mistake, that's why we have a review process. jon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 14:11 ` Jonathan Corbet @ 2013-07-29 16:31 ` Paul Gortmaker 2013-07-29 16:33 ` Jiri Kosina 2013-07-29 22:09 ` Rafael J. Wysocki 1 sibling, 1 reply; 14+ messages in thread From: Paul Gortmaker @ 2013-07-29 16:31 UTC (permalink / raw) To: Jonathan Corbet; +Cc: Rafael J. Wysocki, ksummit-2013-discuss, LKML On 13-07-29 10:11 AM, Jonathan Corbet wrote: > On Mon, 29 Jul 2013 15:10:33 +0200 > "Rafael J. Wysocki" <rjw@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? Try this: $ git describe --contains 8ade62857ef77bdf6391 v3.11-rc1~16^2~103^2^2~5^2~25 Looks scary, but lets deconstruct it right to left a chunk at a time v3.11-rc1 ~16 ^2 ~103 ^2 ^2 ~5 ^2 ~25 So, your commit is 25 commits back in the 2nd branch of the merge described by v3.11-rc1~16^2~103^2^2~5 git show v3.11-rc1~16^2~103^2^2~5 commit 76015021aaaa288bb4dc870258e0acc4d178c950 Merge: f7a01ca fded313 Author: John W. Linville <linville@tuxdriver.com> Date: Mon Jun 10 14:51:17 2013 -0400 Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next which is by definition, 5 commits back from 2nd branch of the merge v3.11-rc1~16^2~103^2 $ git show v3.11-rc1~16^2~103^2 commit 3899ba90a4ab2f3cab8e0f91a76c14ff131c8293 Merge: 45203a3 8b3e7be Author: John W. Linville <linville@tuxdriver.com> Date: Tue Jun 11 14:48:32 2013 -0400 Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem and that merge was merged into the merge v3.11-rc1~16^2~103 git show v3.11-rc1~16^2~103 commit 4a2e667ac15edd19b02321bc030acb3ebeb22ab6 Merge: 8f728d7 3899ba9 Author: David S. Miller <davem@davemloft.net> Date: Wed Jun 12 14:23:41 2013 -0700 Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next which means the above merge was 103 commits back from the last (last = latest/newest) commit on the 2nd arm in merge v3.11-rc1~16 and so on. All the data is there, regardless of whether a maintainer manually manipulated the patch and added a SOB line or not. Paul. -- > > Plus, of course, this assumes there's no fast-forward merges in the mix. > >>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. But most > anybody who works on code occasionally does bad things by mistake, that's > why we have a review process. > > jon > _______________________________________________ > Ksummit-2013-discuss mailing list > Ksummit-2013-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 16:31 ` Paul Gortmaker @ 2013-07-29 16:33 ` Jiri Kosina 0 siblings, 0 replies; 14+ messages in thread From: Jiri Kosina @ 2013-07-29 16:33 UTC (permalink / raw) To: Paul Gortmaker Cc: Jonathan Corbet, Rafael J. Wysocki, ksummit-2013-discuss, LKML On Mon, 29 Jul 2013, Paul Gortmaker 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? > > Try this: > > $ git describe --contains 8ade62857ef77bdf6391 > v3.11-rc1~16^2~103^2^2~5^2~25 > > Looks scary, but lets deconstruct it right to left a chunk at > a time v3.11-rc1 ~16 ^2 ~103 ^2 ^2 ~5 ^2 ~25 > > So, your commit is 25 commits back in the 2nd branch of the merge > described by v3.11-rc1~16^2~103^2^2~5 > > git show v3.11-rc1~16^2~103^2^2~5 > commit 76015021aaaa288bb4dc870258e0acc4d178c950 > Merge: f7a01ca fded313 > Author: John W. Linville <linville@tuxdriver.com> > Date: Mon Jun 10 14:51:17 2013 -0400 > > Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next > > which is by definition, 5 commits back from 2nd branch > of the merge v3.11-rc1~16^2~103^2 > > $ git show v3.11-rc1~16^2~103^2 > commit 3899ba90a4ab2f3cab8e0f91a76c14ff131c8293 > Merge: 45203a3 8b3e7be > Author: John W. Linville <linville@tuxdriver.com> > Date: Tue Jun 11 14:48:32 2013 -0400 > > Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem > > and that merge was merged into the merge v3.11-rc1~16^2~103 > > git show v3.11-rc1~16^2~103 > commit 4a2e667ac15edd19b02321bc030acb3ebeb22ab6 > Merge: 8f728d7 3899ba9 > Author: David S. Miller <davem@davemloft.net> > Date: Wed Jun 12 14:23:41 2013 -0700 > > Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next > > which means the above merge was 103 commits back from the last > (last = latest/newest) commit on the 2nd arm in merge v3.11-rc1~16 > and so on. > > All the data is there, regardless of whether a maintainer manually > manipulated the patch and added a SOB line or not. Alternatively (and that's what I am using) you fire up gitk, and you see all the information almost instantly. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 14:11 ` Jonathan Corbet 2013-07-29 16:31 ` Paul Gortmaker @ 2013-07-29 22:09 ` Rafael J. Wysocki 2013-08-01 10:16 ` Geert Uytterhoeven 1 sibling, 1 reply; 14+ messages in thread From: Rafael J. Wysocki @ 2013-07-29 22:09 UTC (permalink / raw) To: Jonathan Corbet Cc: Jiri Kosina, Samuel Ortiz, ksummit-2013-discuss, LKML, Paul Gortmaker, Jiri Kosina On Monday, July 29, 2013 08:11:41 AM Jonathan Corbet wrote: > On Mon, 29 Jul 2013 15:10:33 +0200 > "Rafael J. Wysocki" <rjw@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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 22:09 ` Rafael J. Wysocki @ 2013-08-01 10:16 ` Geert Uytterhoeven 2013-08-01 17:40 ` Rafael J. Wysocki 0 siblings, 1 reply; 14+ messages in thread From: Geert Uytterhoeven @ 2013-08-01 10:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jonathan Corbet, Jiri Kosina, Samuel Ortiz, ksummit-2013-discuss, LKML, Paul Gortmaker On Tue, Jul 30, 2013 at 12:09 AM, Rafael J. Wysocki <rjw@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?). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-08-01 10:16 ` Geert Uytterhoeven @ 2013-08-01 17:40 ` Rafael J. Wysocki 0 siblings, 0 replies; 14+ messages in thread From: Rafael J. Wysocki @ 2013-08-01 17:40 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Jonathan Corbet, Jiri Kosina, Samuel Ortiz, ksummit-2013-discuss, LKML, Paul Gortmaker On Thursday, August 01, 2013 12:16:40 PM Geert Uytterhoeven wrote: > On Tue, Jul 30, 2013 at 12:09 AM, Rafael J. Wysocki <rjw@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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20130729113526.GB3604@zurbaran>]
[parent not found: <20130729130357.GQ29916@titan.lakedaemon.net>]
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process [not found] ` <20130729130357.GQ29916@titan.lakedaemon.net> @ 2013-07-29 13:27 ` Rafael J. Wysocki 2013-07-29 18:17 ` John W. Linville 0 siblings, 1 reply; 14+ messages in thread From: Rafael J. Wysocki @ 2013-07-29 13:27 UTC (permalink / raw) To: Jason Cooper, Samuel Ortiz Cc: ksummit-2013-discuss, LKML, Jonathan Corbet, Linus Torvalds On Monday, July 29, 2013 09:03:57 AM Jason Cooper wrote: > On Mon, Jul 29, 2013 at 01:35:26PM +0200, Samuel Ortiz wrote: > > On Mon, Jul 29, 2013 at 06:40:32AM -0400, Jason Cooper wrote: > > > On Mon, Jul 29, 2013 at 12:31:37PM +0200, Jiri Kosina wrote: > > > > On Mon, 29 Jul 2013, Samuel Ortiz wrote: > > > > > > > > > - Developement process: Jon Corbet's article about our changelog raised > > > > > one interesting question: How can we better track how single SOB > > > > > patches are getting merged ? Should maintainers add their SOB when > > > > > they pull from subsystems maintainers (If they can) ? This is > > > > > something I care about from both my MFD and NFC maintainer > > > > > perspectives as I both pull from MFD sub maintainers and am John > > > > > Linville's NFC sub maintainer. > > > > > > > > This is difficult ... I think that in some sense merging from subsystem > > > > maintainer tree can be viewed as an "implicit" Signoff, although this > > > > hasn't been formalized anywhere. > > > > > > > > I am afraid there is no way git could handle this easily without rebasing. > > > > > > And that breaks workflows where eg sub-maintainer and maintainer both > > > contribute to linux-next. commit-id's _must_ match. As an example, our > > > mvebu tree and arm-soc both contribute to linux-next and arm-soc pulls > > > our branches. > > > > Yes, I'm not saying we should rebase, don't get me wrong. > > > > > Perhaps the merge commit is the place for this? > > > > That would be a first step, but that would obviously not fix the single > > SOB patches issue. > > Well, is this that maintainers aren't adding a SoB when they apply > patches from others? Or, that maintainers are applying their own > patches, potentially without review? The purported issue seems to be that some maintainers may apply their own patches without review and then those commits are difficult to track. I honestly don't think they are difficult to track as I said here: http://marc.info/?l=linux-kernel&m=137510284529196&w=4 Whether or not those patches are applied without review is difficult to establish even if they are posted to mailing lists before applying. That said we have the same issue with commits with just two SOB tags if a maintainer applies a patch that nobody has responded to. Are they going to be regarded as "suspicious" too now? 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? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 13:27 ` Rafael J. Wysocki @ 2013-07-29 18:17 ` John W. Linville 2013-07-29 18:41 ` Jason Cooper 2013-07-29 22:30 ` Rafael J. Wysocki 0 siblings, 2 replies; 14+ messages in thread From: John W. Linville @ 2013-07-29 18:17 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jason Cooper, Samuel Ortiz, ksummit-2013-discuss, Linus Torvalds, LKML On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: > That said we have the same issue with commits with just two SOB tags if > a maintainer applies a patch that nobody has responded to. Are they going to > be regarded as "suspicious" too now? > > 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? Not just Linus -- it's 'turtles all the way down' here. As someone else suggested, a Singed-off-by in the merge commit should suffice here. Although, I haven't always made a habit of adding S-o-b to merge commits either... John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 18:17 ` John W. Linville @ 2013-07-29 18:41 ` Jason Cooper 2013-07-29 22:30 ` Rafael J. Wysocki 1 sibling, 0 replies; 14+ messages in thread From: Jason Cooper @ 2013-07-29 18:41 UTC (permalink / raw) To: John W. Linville Cc: Rafael J. Wysocki, Samuel Ortiz, ksummit-2013-discuss, Linus Torvalds, LKML On Mon, Jul 29, 2013 at 02:17:34PM -0400, John W. Linville wrote: > On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: > > > That said we have the same issue with commits with just two SOB tags if > > a maintainer applies a patch that nobody has responded to. Are they going to > > be regarded as "suspicious" too now? > > > > 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? > > Not just Linus -- it's 'turtles all the way down' here. As someone > else suggested, a Singed-off-by in the merge commit should suffice > here. Although, I haven't always made a habit of adding S-o-b to > merge commits either... Even then, you are the author of the merge commit. So the original question of tracking a 'chain-of-custody' from submitter to Linus' tree is still answerable. Even if there is only a single SoB in the patch. thx, Jason. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 18:17 ` John W. Linville 2013-07-29 18:41 ` Jason Cooper @ 2013-07-29 22:30 ` Rafael J. Wysocki 2013-07-31 5:47 ` H. Peter Anvin 1 sibling, 1 reply; 14+ messages in thread From: Rafael J. Wysocki @ 2013-07-29 22:30 UTC (permalink / raw) To: John W. Linville Cc: Jason Cooper, Samuel Ortiz, ksummit-2013-discuss, Linus Torvalds, LKML On Monday, July 29, 2013 02:17:34 PM John W. Linville wrote: > On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: > > > That said we have the same issue with commits with just two SOB tags if > > a maintainer applies a patch that nobody has responded to. Are they going to > > be regarded as "suspicious" too now? > > > > 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? > > Not just Linus -- it's 'turtles all the way down' here. As someone > else suggested, a Singed-off-by in the merge commit should suffice > here. Although, I haven't always made a habit of adding S-o-b to > merge commits either... An SOB in the merge doesn't provide any additional information that can't be retrieved from git, unless you use a different e-mail address for the sign-off. :-) Rafael ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-29 22:30 ` Rafael J. Wysocki @ 2013-07-31 5:47 ` H. Peter Anvin 2013-07-31 5:56 ` James Bottomley 2013-07-31 11:48 ` Rafael J. Wysocki 0 siblings, 2 replies; 14+ messages in thread From: H. Peter Anvin @ 2013-07-31 5:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: John W. Linville, LKML, ksummit-2013-discuss, Linus Torvalds, Jason Cooper On 07/29/2013 03:30 PM, Rafael J. Wysocki wrote: > On Monday, July 29, 2013 02:17:34 PM John W. Linville wrote: >> On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: >> >>> That said we have the same issue with commits with just two SOB tags if >>> a maintainer applies a patch that nobody has responded to. Are they going to >>> be regarded as "suspicious" too now? >>> >>> 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? >> >> Not just Linus -- it's 'turtles all the way down' here. As someone >> else suggested, a Singed-off-by in the merge commit should suffice >> here. Although, I haven't always made a habit of adding S-o-b to >> merge commits either... > > An SOB in the merge doesn't provide any additional information that can't > be retrieved from git, unless you use a different e-mail address for the > sign-off. :-) > Watch out for fast forward merges. Ideally I guess maintainers really should disable fast forwards and PGP-sign their merge commits... -hpa ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-31 5:47 ` H. Peter Anvin @ 2013-07-31 5:56 ` James Bottomley 2013-07-31 11:48 ` Rafael J. Wysocki 1 sibling, 0 replies; 14+ messages in thread From: James Bottomley @ 2013-07-31 5:56 UTC (permalink / raw) To: H. Peter Anvin Cc: Rafael J. Wysocki, ksummit-2013-discuss, Linus Torvalds, Jason Cooper, LKML On Tue, 2013-07-30 at 22:47 -0700, H. Peter Anvin wrote: > On 07/29/2013 03:30 PM, Rafael J. Wysocki wrote: > > On Monday, July 29, 2013 02:17:34 PM John W. Linville wrote: > >> On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: > >> > >>> That said we have the same issue with commits with just two SOB tags if > >>> a maintainer applies a patch that nobody has responded to. Are they going to > >>> be regarded as "suspicious" too now? > >>> > >>> 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? > >> > >> Not just Linus -- it's 'turtles all the way down' here. As someone > >> else suggested, a Singed-off-by in the merge commit should suffice > >> here. Although, I haven't always made a habit of adding S-o-b to > >> merge commits either... > > > > An SOB in the merge doesn't provide any additional information that can't > > be retrieved from git, unless you use a different e-mail address for the > > sign-off. :-) > > > > Watch out for fast forward merges. Ideally I guess maintainers really > should disable fast forwards and PGP-sign their merge commits... If you always pull from a signed tag, this isn't a problem. James ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process 2013-07-31 5:47 ` H. Peter Anvin 2013-07-31 5:56 ` James Bottomley @ 2013-07-31 11:48 ` Rafael J. Wysocki 1 sibling, 0 replies; 14+ messages in thread From: Rafael J. Wysocki @ 2013-07-31 11:48 UTC (permalink / raw) To: H. Peter Anvin Cc: John W. Linville, LKML, ksummit-2013-discuss, Linus Torvalds, Jason Cooper On Tuesday, July 30, 2013 10:47:31 PM H. Peter Anvin wrote: > On 07/29/2013 03:30 PM, Rafael J. Wysocki wrote: > > On Monday, July 29, 2013 02:17:34 PM John W. Linville wrote: > >> On Mon, Jul 29, 2013 at 03:27:44PM +0200, Rafael J. Wysocki wrote: > >> > >>> That said we have the same issue with commits with just two SOB tags if > >>> a maintainer applies a patch that nobody has responded to. Are they going to > >>> be regarded as "suspicious" too now? > >>> > >>> 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? > >> > >> Not just Linus -- it's 'turtles all the way down' here. As someone > >> else suggested, a Singed-off-by in the merge commit should suffice > >> here. Although, I haven't always made a habit of adding S-o-b to > >> merge commits either... > > > > An SOB in the merge doesn't provide any additional information that can't > > be retrieved from git, unless you use a different e-mail address for the > > sign-off. :-) > > > > Watch out for fast forward merges. Ideally I guess maintainers really > should disable fast forwards and PGP-sign their merge commits... If you submit a signed pull request, that covers all of the history in your tree up to the top commit you're requesting to pull. And I don't do fast forward merges. Thanks, Rafael ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-08-01 17:30 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20130729102452.GA2682@zurbaran>
[not found] ` <alpine.LNX.2.00.1307291230270.18809@pobox.suse.cz>
2013-07-29 13:10 ` [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process Rafael J. Wysocki
2013-07-29 14:11 ` Jonathan Corbet
2013-07-29 16:31 ` Paul Gortmaker
2013-07-29 16:33 ` Jiri Kosina
2013-07-29 22:09 ` Rafael J. Wysocki
2013-08-01 10:16 ` Geert Uytterhoeven
2013-08-01 17:40 ` Rafael J. Wysocki
[not found] ` <20130729113526.GB3604@zurbaran>
[not found] ` <20130729130357.GQ29916@titan.lakedaemon.net>
2013-07-29 13:27 ` Rafael J. Wysocki
2013-07-29 18:17 ` John W. Linville
2013-07-29 18:41 ` Jason Cooper
2013-07-29 22:30 ` Rafael J. Wysocki
2013-07-31 5:47 ` H. Peter Anvin
2013-07-31 5:56 ` James Bottomley
2013-07-31 11:48 ` Rafael J. Wysocki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.