[OE-core] Patch message guidelines and internal/corporate fields

[Paul Eggleton]

On Saturday 23 August 2014 09:40:44 Richard Purdie wrote:
> On Fri, 2014-08-22 at 10:24 -0500, Richard Tollerton wrote:
> > Randy MacLeod <randy.macleod at windriver.com> writes:
> > > Wind River patches used to include a "CQID" tag but we've changed
> > > our process to avoid needing such internal tags. If National
> > > Instruments can do so as well, that'd be best.
> > > 
> > > I did check my oe-core email list history and this seems like the
> > > first patch from NI that has the tags included so I thought
> > > I'd reply and see if we can get the tags dropped.
> > 
> > IIRC, we pinged Phil a few months ago on this topic, and he thought
> > internal tags were OK. I think Wind River might have been cited as an
> > example.
> > 
> > I see that
> > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines hasn't
> > been updated with this requirement. Should it be? Will that require TSC
> > approval?
> 
> I don't have a strong preference on this to be honest. I can imagine
> cases where its useful to have some kind of tracking of issues into the
> final commits.
> 
> Obviously it would be better if everyone can understand what the numbers
> mean, equally, it seems pointless to force people to strip them when
> they might be useful to people contributing to the project.
> 
> If they are used as a substitute for a good commit message, that
> wouldn't be acceptable. Also, if they were taking over the commit
> messages, that would able be unacceptable. So if we can keep them to a
> small part of the commit, I'm prepared to let them pass but it can't be
> at the expense of good commit messages.
> 
> I don't believe we need a TSC decision, that would only be needed if
> there were strong disagreements we were unable to resolve and I don't
> think we're quite there yet :) I'll let others comment though and see
> where we're at.

FWIW I agree with all of the above - if they make contributors' lives easier 
then I don't see a good reason to disallow their usage given we're only 
talking about one line at the end of a proper commit message.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre