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.
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
[email protected] might be all we have. Be ready.
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.
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
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
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
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