Adding links to Google's internal bug tracker

[Ben Rohlfs]

Hi all,

The Google developer team often makes changes in response to internal bug reports or uses internal tracking bugs. So we would like to be allowed to reference these issues in the footer of commit messages of our changes like so:

Bug: Google b/186495870

Example change: https://gerrit-review.googlesource.com/c/gerrit/+/309964

We understand that this is not ideal, because non-Googlers cannot open these links. But for Google employees these links can be really helpful. Please call us out, if you think that the Google internal issue is hiding valuable information from you. We are committed to making the commit message speak for itself.

Please speak up, if you think that adding such Google internal links to Gerrit's commit messages is not a good idea.

Thanks, Ben

[Edwin Kempin]

Thanks Ben for suggesting this.

This would be a big improvement for the Gerrit team at Google and I'm hopeful that it's not too disturbing for non-Googlers. 

I would be really happy if we could do this!

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAEWS%2BaNtG%3DmjxMp5n5PqgfybDKGFDFHj9JsHGw%2BgwxkNO8mAmg%40mail.gmail.com.

[Sven Selberg]

On Wednesday, June 23, 2021 at 12:02:44 PM UTC+2 Edwin Kempin wrote:

On Wed, Jun 23, 2021 at 11:45 AM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Hi all,

The Google developer team often makes changes in response to internal bug reports or uses internal tracking bugs.

As do we all.

We solve it by:

1. Creating an upstream issue

2. Link the internal issue to the upstream issue.

3. Link the internal issue to any changes uploaded to gerrit-review that solves the issue.

Which is a bit of extra manual work and you guys probably solve a lot more internally triggered issues upstream than we do.

So we would like to be allowed to reference these issues in the footer of commit messages of our changes like so:

Bug: Google b/186495870

Example change: https://gerrit-review.googlesource.com/c/gerrit/+/309964

We understand that this is not ideal, because non-Googlers cannot open these links. But for Google employees these links can be really helpful. Please call us out, if you think that the Google internal issue is hiding valuable information from you. We are committed to making the commit message speak for itself.

 

It's fine by me but then it's very important to duplicate vital context information from the issue to the commit message.

I feel that the example change is a prime example of when this isn't done. Nowhere in the commit message is it clear what the commit tries to accomplish/solve and why.
No offense but "Update the visual of "Not logged in" for Checks in change summary" is bordering on "Changed stuff".
I'm sure there's a reason in the internal bug report, so for anyone with access to the internal bug-tracker it should makes perfect sense.

It's generally very difficult to recognize which pieces of information, visible to you, are visible to other people.

[Christian Gagneraud]

On Wed, 23 Jun 2021 at 22:02, 'Edwin Kempin' via Repo and Gerrit

Discussion <repo-d...@googlegroups.com> wrote:
> On Wed, Jun 23, 2021 at 11:45 AM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>>
>> Hi all,
>>
>> The Google developer team often makes changes in response to internal bug reports or uses internal tracking bugs. So we would like to be allowed to reference these issues in the footer of commit messages of our changes like so:
>>
>> Bug: Google b/186495870
>>
>> Example change: https://gerrit-review.googlesource.com/c/gerrit/+/309964
>>
>> We understand that this is not ideal, because non-Googlers cannot open these links. But for Google employees these links can be really helpful. Please call us out, if you think that the Google internal issue is hiding valuable information from you. We are committed to making the commit message speak for itself.
>>
>> Please speak up, if you think that adding such Google internal links to Gerrit's commit messages is not a good idea.

Hi all,

I came across these refs in AOSP quite often, and yes it is quite
frustrating to not have access to the details. You just stare at a
number and you have no clue what's going on...
I have no realistic solution to propose.

FWIW,
Chris

[Ben Rohlfs]

We solve it by: [...]

Which is a bit of extra manual work and you guys probably solve a lot more internally triggered issues upstream than we do.

We are developing so many changes such that the amount of extra work is substantial and the reality/alternative is that we just don't link to anything. :-/

I feel that the example change is a prime example of when this isn't done. Nowhere in the commit message is it clear what the commit tries to accomplish/solve and why. No offense but "Update the visual of "Not logged in" for Checks in change summary" is bordering on "Changed stuff".

Well, the internal issue is mostly just Delphine providing some mocks and specs to me. The reason for "update the visual" often is just "because it looks nicer", and note that I have taken the trouble to create and link a screenshot. Anyway, I have also added another sentence to my commit message. Glad that someone reads them, which most of the time nobody does apart from my reviewers. :-)

-Ben

[Edwin Kempin]

I agree that it's important that the commit message must contain all relevant details.

But just omitting the bug reference is not making this happen. I wish reviewers would insist on better commit messages more often.

 

You just stare at a
number and you have no clue what's going on...

That's the reason why we want to prefix the issue number with "Google", so that everyone can see at a glance that this is a Google internal issue reference, and doesn't get confused/frustrated that it's not resolving for them.

 

I have no realistic solution to propose.

FWIW,
Chris

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CABxGUTjXm_3%3D6mb4B9PMf7wif0yEDfEH73%3Dr4peCQ8KD7x4pag%40mail.gmail.com.

[Sven Selberg]

On Wednesday, June 23, 2021 at 1:06:19 PM UTC+2 bro...@google.com wrote:

We solve it by: [...]

Which is a bit of extra manual work and you guys probably solve a lot more internally triggered issues upstream than we do.

We are developing so many changes such that the amount of extra work is substantial and the reality/alternative is that we just don't link to anything. :-/

Ack! 

I feel that the example change is a prime example of when this isn't done. Nowhere in the commit message is it clear what the commit tries to accomplish/solve and why. No offense but "Update the visual of "Not logged in" for Checks in change summary" is bordering on "Changed stuff".

Well, the internal issue is mostly just Delphine providing some mocks and specs to me. The reason for "update the visual" often is just "because it looks nicer", and note that I have taken the trouble to create and link a screenshot. Anyway, I have also added another sentence to my commit message. Glad that someone reads them, which most of the time nobody does apart from my reviewers. :-)

Perhaps it was a bit unfair to criticise the example change since it was so non-vital that the difference between too-little and too-much information is razor thin.

But to tool-shed a bit:  IMO "Make Checks' "Not logged in" in change summary look better" is preferable since it explains why and this is probably evident in the internal issue.

To be clear:
I don't have any problem with it apart from the gnawing feeling of missing out on whatever hides behind the secret reference ;-)

-Ben

[Christian Gagneraud]

On Wed, 23 Jun 2021 at 23:12, Edwin Kempin <eke...@google.com> wrote:
> On Wed, Jun 23, 2021 at 1:01 PM Christian Gagneraud <chg...@gmail.com> wrote:
>>
>> On Wed, 23 Jun 2021 at 22:02, 'Edwin Kempin' via Repo and Gerrit
>> Discussion <repo-d...@googlegroups.com> wrote:
>> > On Wed, Jun 23, 2021 at 11:45 AM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> The Google developer team often makes changes in response to internal bug reports or uses internal tracking bugs. So we would like to be allowed to reference these issues in the footer of commit messages of our changes like so:
>> >>
>> >> Bug: Google b/186495870
>> >>
>> >> Example change: https://gerrit-review.googlesource.com/c/gerrit/+/309964
>> >>
>> >> We understand that this is not ideal, because non-Googlers cannot open these links. But for Google employees these links can be really helpful. Please call us out, if you think that the Google internal issue is hiding valuable information from you. We are committed to making the commit message speak for itself.
>> >>
>> >> Please speak up, if you think that adding such Google internal links to Gerrit's commit messages is not a good idea.
>>
>> Hi all,
>>
>> I came across these refs in AOSP quite often, and yes it is quite
>> frustrating to not have access to the details.
>
> I agree that it's important that the commit message must contain all relevant details.
> But just omitting the bug reference is not making this happen. I wish reviewers would insist on better commit messages more often.

Agree, example in AOSP:
# b/113232673 STOPSHIP deal with Qualcomm stuff later

It's STOPSHIP, but has been shipped (to the open source community),
how confusing.

I don't really care that Google and Qualcomm are having some issues,
but i would be interested to know what the issue is about, eg:
# b/113232673 STOPSHIP SoC vendor shouldn't do foo, bar, baz b/c it
creates problem with A, B, C

This would give me clues about what the problem is, would help me to
make sure i don't do the same (or be suspicious when i see one from
another SoC vendor), yet it wouldn't tell me anything about Google
internal problems with Qualcomm.

Hope this helps.

Chris

[Edwin Kempin]

On Wednesday, June 23, 2021 at 1:42:11 PM UTC+2 chg...@gmail.com wrote:

On Wed, 23 Jun 2021 at 23:12, Edwin Kempin <eke...@google.com> wrote:
> On Wed, Jun 23, 2021 at 1:01 PM Christian Gagneraud <chg...@gmail.com> wrote:
>>
>> On Wed, 23 Jun 2021 at 22:02, 'Edwin Kempin' via Repo and Gerrit
>> Discussion <repo-d...@googlegroups.com> wrote:
>> > On Wed, Jun 23, 2021 at 11:45 AM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> The Google developer team often makes changes in response to internal bug reports or uses internal tracking bugs. So we would like to be allowed to reference these issues in the footer of commit messages of our changes like so:
>> >>
>> >> Bug: Google b/186495870
>> >>
>> >> Example change: https://gerrit-review.googlesource.com/c/gerrit/+/309964
>> >>
>> >> We understand that this is not ideal, because non-Googlers cannot open these links. But for Google employees these links can be really helpful. Please call us out, if you think that the Google internal issue is hiding valuable information from you. We are committed to making the commit message speak for itself.
>> >>
>> >> Please speak up, if you think that adding such Google internal links to Gerrit's commit messages is not a good idea.

Today we discussed this in the joined ESC and community manager meeting and the conclusion was that it's OK to go ahead with this.

If we find that it's causing issue we need to re-discuss.

When doing this please remember that:

- commit messages should always contain all relevant information

- important issues that are relevant to the community should be made available in Monorail