[Ksummit-2013-discuss] [ATTEND] DT, maintainership, development process

Jason Cooper jason at lakedaemon.net
Mon Jul 29 13:03:57 UTC 2013


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?

thx,

Jason.


More information about the Ksummit-2013-discuss mailing list