[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