Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] master 599b880: Handle the UTC timestamp
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Gerald Combs <gerald@xxxxxxxxxxxxx>
Date: Fri, 11 Jul 2014 13:03:50 -0700
On 7/7/14 9:10 PM, Evan Huus wrote:
> On Sun, Jul 6, 2014 at 12:59 PM, Alexis La Goutte
> <alexis.lagoutte@xxxxxxxxx <mailto:alexis.lagoutte@xxxxxxxxx>> wrote:
> 
>     On Sat, Jul 5, 2014 at 11:49 PM, Evan Huus <eapache@xxxxxxxxx


>     > It would be nice to have different tags for Refs-Bug and
>     Fixes-Bug, and have
>     > the bugzilla integration do The Right Thing for changes that refer
>     to but do
>     > not fix a bug. Gerald, how easy is this? I believe OpenStack has a
>     set of
>     > tags they use which we might look to for inspiration?
>     +1
>     I like OpenStack tags :
> 
>     Closes-Bug: #1234567 -- use 'Closes-Bug' if the commit is intended to
>     fully fix and close the bug being referenced.
>     Partial-Bug: #1234567 -- use 'Partial-Bug' if the commit is only a
>     partial fix and more work is needed.
>     Related-Bug: #1234567 -- use 'Related-Bug' if the commit is merely
>     related to the referenced bug.
> 
> 
>     https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references

How would Partial-Bug and Related-Bug differ for our purposes? Wouldn't
they do the same thing (i.e. add a comment to the bug)? Could we get
away with two tags:

Ping-Bug: 12345 -- Add a comment to bug 12345
Bug (or Closes-Bug): 12345 -- Add a comment and mark it RESOLVED FIXED.


> On a related note, Gerrit has stopped commenting when a new patchset is
> uploaded referencing a bug (I assume because it wasn't super-useful and
> was causing noise). It would still be useful though, I think, if it add
> a comment for new changes (just not for new patchsets within each
> change) if that is possible.

I tried to modify the "patchset-created" rule to only add a comment for
the first change. In at least one case subsequent revisions were
spamming the bug with the same comment. It looks like the rule had a
bug. It should be fixed now.