[Gluster-devel] Proposal to change Gerrit -> Bugzilla updates

[Nigel Babu]

On Mon, Sep 10, 2018 at 7:08 PM Shyam Ranganathan <srangana at redhat.com>
wrote:

> My assumption here is that for each patch that mentions a BZ, an
> additional tracker would be added to the tracker list, right?
>

Correct.


>
> Further assumption (as I have not used trackers before) is that this
> would reduce noise as comments in the bug itself, right?
>

There is two goals - One two see all the patches posted at the start of the
bug. The reduction of noise is a good bonus to have.


>
> In the past we have reduced noise by not commenting on the bug (or
> github issue) every time the patch changes, so we get 2 comments per
> patch currently, with the above change we would just get one and that
> too as a terse external reference (see [1], based on my
> test/understanding).
>
> What we would lose is the commit details when the patch is merged in the
> BZ, as far as I can tell based on the changes below. These are useful
> and would like these to be retained in case they are not.
>

I'm okay to do that.


>
> > 2. When a patch is merged, only change state of the bug if needed. If
> > there is no state change, do not add an additional message. The external
> > tracker state should change reflecting the state of the review.
>
> I added a tracker to this bug [1], but not seeing the tracker state
> correctly reflected in BZ, is this work that needs to be done?
>

Huh. That's odd. This works way better with other trackers. I'll follow up
with the Bugzilla folks to see how to chase this down. Ideally it should
show the state change (however, with no notification on the bug as far as I
can understand. Given that you're for keeping the notification, at this
point, all that's extra is we'll add a tracker for every new bug.


>
> > 3. Assign the bug to the committer. This has edge cases, but it's best
> > to at least handle the easy ones and then figure out edge cases later.
> > The experience is going to be better than what it is right now.
>
> Is the above a reference to just the "assigned to", or overall process?
> If overall can you elaborate a little more on why this would be better
> (I am not saying it is not, attempting to understand how you see it).
>

It's a reference just to the "assigned to". I don't yet know who has their
gerrit emails mapped to their bugzilla IDs. Automatic assigning will only
work if that matrix is perfectly matched. So, when we start doing this, it
will fail for a bunch of users. We'll have to tune this over time to
develop a matrix of Gerrit email -> Bugzilla email.


>
> >
> > Please provide feedback/comments by end of day Friday. I plan to add
> > this activity to the next Infra team sprint that starts on Monday (Sep
> 17).
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1619423
>


-- 
nigelb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180911/6c991b1b/attachment.html>