Proprietary task references in commit logs

Proprietary task references in commit logs

[Alexander Amelkin]

Hi all.

Do you think it is acceptable to have a reference to a proprietary task 
ID in a commit log?

We're using JIRA and would like to see related commits displayed in the 
corresponding issue. That requires putting the issue ID into the commit 
log, so the log would look something like this:

===========

Fix some bug (less than 50 chars as usual)

Long description goes here.
Multiple lines, each less than 72 characters, as usual.

Company Ref: KEY-1234

Change-Id: I5e0f94d168a61b6d82214779aa6ebd9796dc37b2
Signed-off-by: The Author <t.author@company.tld>

===========

Any comments are welcome.

Re: Proprietary task references in commit logs

[Patrick Venture]

Alexander;

So, we've been in a similar boat, in that we have a Google-Bug-Id in
all our commits.  However, for openbmc we've been trimming them out.
I think part of the argument is to keep the commit message clean, or
if necessary file a corresponding bug in the openbmc bug track, and
then close that bug id.

Can you point the jira bug to the github bug track?

Patrick

On Tue, Feb 13, 2018 at 5:13 AM, Alexander Amelkin <a.amelkin@yadro.com> wrote:
> Hi all.
>
> Do you think it is acceptable to have a reference to a proprietary task ID
> in a commit log?
>
> We're using JIRA and would like to see related commits displayed in the
> corresponding issue. That requires putting the issue ID into the commit log,
> so the log would look something like this:
>
> ===========
>
> Fix some bug (less than 50 chars as usual)
>
> Long description goes here.
> Multiple lines, each less than 72 characters, as usual.
>
> Company Ref: KEY-1234
>
> Change-Id: I5e0f94d168a61b6d82214779aa6ebd9796dc37b2
> Signed-off-by: The Author <t.author@company.tld>
>
> ===========
>
> Any comments are welcome.
>

Re: Proprietary task references in commit logs

[Stewart Smith]

Patrick Venture <venture@google.com> writes:
> Alexander;
>
> So, we've been in a similar boat, in that we have a Google-Bug-Id in
> all our commits.  However, for openbmc we've been trimming them out.
> I think part of the argument is to keep the commit message clean, or
> if necessary file a corresponding bug in the openbmc bug track, and
> then close that bug id.

I've been poked at this for other firmware too, and I tend to dislike
non-public bug tracker IDs in public repositories.

I have an idea of using git-notes to have a local tree of `fixes` (even
added retroactively) that could then be queried/modified that would suit
this kind of use case.

Of course, finding enough time to write the couple of hundred lines of
python to do that has been elusive :)

-- 
Stewart Smith
OPAL Architect, IBM.

Re: Proprietary task references in commit logs

[Alexander Amelkin]

14.02.2018 06:30, Stewart Smith wrote:
> I've been poked at this for other firmware too, and I tend to dislike
> non-public bug tracker IDs in public repositories.
>
> I have an idea of using git-notes to have a local tree of `fixes` (even
> added retroactively) that could then be queried/modified that would suit
> this kind of use case.
>
> Of course, finding enough time to write the couple of hundred lines of
> python to do that has been elusive :)
Exactly! This is all about extra work to do, no time to do it, and 
elusive profit of that effort.
Adding a non-public ID takes almost no effort, as well as ignoring it in 
the logs just like most people ignore those strange lawyer-induced 
"Signed-off-by" lines or purely technical "Change-Id" lines.

Creating a separate 'bug' in OpenBMC bugtracker (unless we start to 
require a formal 'bug' for each commit) and adding its ID to the local 
bug-tracker is a useless waste of time, IMO.

Each commit would at max have just one extra company tracker reference 
line. Is that really a problem?

Alexander.

Re: Proprietary task references in commit logs

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Wed, 2018-02-14 at 11:07 +0300, Alexander Amelkin wrote:
> 14.02.2018 06:30, Stewart Smith wrote:
> > I've been poked at this for other firmware too, and I tend to dislike
> > non-public bug tracker IDs in public repositories.
> > 
> > I have an idea of using git-notes to have a local tree of `fixes` (even
> > added retroactively) that could then be queried/modified that would suit
> > this kind of use case.
> > 
> > Of course, finding enough time to write the couple of hundred lines of
> > python to do that has been elusive :)
> 
> Exactly! This is all about extra work to do, no time to do it, and 
> elusive profit of that effort.

Stewart might not have the time to do it himself, but I agree with his
direction and disagree with taking your suggested shortcut[0]. We
should find someone with the time to sort it out properly. Please open
an issue against OpenBMC where the details can be hashed out if you
feel this is a significant deficiency.

Cheers,

Andrew

[0] as someone who wants to see the issue tracker free of internal
identifiers as well

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Proprietary task references in commit logs

[Patrick Williams]

If you allow proprietary references you have the general problem of who's tracking reference do you use when multiple organizations have discovered and are tracking the same issue. First one to submit code?  Everyone's? Are we going to end up with extra patchsets so everyone can put their own proprietary tracker in?  What happens when the fix has already been merged and then you discover it internally?

We'd not rewrite git history to get references into already released fixes. So you have to deal with that case anyhow. The best way to solve that case is that your internal tracker contains the Gerrit ChangeId(s) related to the problem. And once you do that, you can do the same for unmerged fixes.

Recommendation (which other orgs are already doing): Reference Gerrit IDs in JIRA rather than having Gerrit commits reference JIRA. 

Patrick
Sent from my iPhone

> On Feb 15, 2018, at 7:03 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> 
>> On Wed, 2018-02-14 at 11:07 +0300, Alexander Amelkin wrote:
>> 14.02.2018 06:30, Stewart Smith wrote:
>>> I've been poked at this for other firmware too, and I tend to dislike
>>> non-public bug tracker IDs in public repositories.
>>> 
>>> I have an idea of using git-notes to have a local tree of `fixes` (even
>>> added retroactively) that could then be queried/modified that would suit
>>> this kind of use case.
>>> 
>>> Of course, finding enough time to write the couple of hundred lines of
>>> python to do that has been elusive :)
>> 
>> Exactly! This is all about extra work to do, no time to do it, and 
>> elusive profit of that effort.
> 
> Stewart might not have the time to do it himself, but I agree with his
> direction and disagree with taking your suggested shortcut[0]. We
> should find someone with the time to sort it out properly. Please open
> an issue against OpenBMC where the details can be hashed out if you
> feel this is a significant deficiency.
> 
> Cheers,
> 
> Andrew
> 
> [0] as someone who wants to see the issue tracker free of internal
> identifiers as well