linux-kernel - Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Jul 2013 15:27:44 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Jason Cooper <jason@...edaemon.net>,
	Samuel Ortiz <sameo@...ux.intel.com>
Cc:	ksummit-2013-discuss@...ts.linuxfoundation.org,
	LKML <linux-kernel@...r.kernel.org>,
	Jonathan Corbet <corbet@....net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/