Re: Patch message guidelines and internal/corporate fields

[Khem Raj <raj.khem@gmail.com>]

On 14-08-24 16:33:39, Paul Eggleton wrote:
> 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@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.

I would rather think that if the information is not accessible to community
members, its not a useful to add these numbers. Secondly it could be fixing
someone else's bug in a different bug tracking system with different
tracking number and if he she does a backport and adds his tracking
number as well to commit. Now think of what will happen if people start
to do it for Linux kernel. So IMHO its best that companies track it in
their respective issue tracking systems by adding upstream commit urls or SHA ids
whatever is convinient to support any automation tools they might
have(if any) That way we solve the problem for everyone. On
these grounds I would not recommend adding it in commit messages. We let Yocto
bugzilla entries in commits because that system is accessible to everyone using OE.

Thanks

-Khem