Proprietary task references in commit logs

Patrick Williams patrick at stwcx.xyz
Wed Feb 21 23:38:03 AEDT 2018


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 at 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




More information about the openbmc mailing list