<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 9:25 PM, Atin Mukherjee <span dir="ltr"><<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Sep 10, 2018 at 7:09 PM Shyam Ranganathan <<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/10/2018 08:37 AM, Nigel Babu wrote:<br>
> Hello folks,<br>
> <br>
> We now have <a href="http://review.gluster.org" rel="noreferrer" target="_blank">review.gluster.org</a> <<a href="http://review.gluster.org" rel="noreferrer" target="_blank">http://review.gluster.org</a>> as an<br>
> external tracker on Bugzilla. Our current automation when there is a<br>
> bugzilla attached to a patch is as follows:<br>
> <br>
> 1. When a new patchset has "Fixes: bz#1234" or "Updates: bz#1234", we<br>
> will post a comment to the bug with a link to the patch and change the<br>
> status to POST. 2. When the patchset is merged, if the commit said<br>
> "Fixes", we move the status to MODIFIED.<br>
> <br>
> I'd like to propose the following improvements:<br>
> 1. Add the Gerrit URL as an external tracker to the bug.<br>
<br>
My assumption here is that for each patch that mentions a BZ, an<br>
additional tracker would be added to the tracker list, right?<br>
<br>
Further assumption (as I have not used trackers before) is that this<br>
would reduce noise as comments in the bug itself, right?<br>
<br>
In the past we have reduced noise by not commenting on the bug (or<br>
github issue) every time the patch changes, so we get 2 comments per<br>
patch currently, with the above change we would just get one and that<br>
too as a terse external reference (see [1], based on my test/understanding).<br>
<br>
What we would lose is the commit details when the patch is merged in the<br>
BZ, as far as I can tell based on the changes below. These are useful<br>
and would like these to be retained in case they are not.<br></blockquote><div><br></div></span><div>The commit at the bugzilla has been extremely helpful, in fact I could refer to the commit details to understand what has been fixed for the bug when r.g.o was down in couple of instances. So my vote would be to stick to the same.</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 2. When a patch is merged, only change state of the bug if needed. If<br>
> there is no state change, do not add an additional message. The external<br>
> tracker state should change reflecting the state of the review.<br>
<br>
I added a tracker to this bug [1], but not seeing the tracker state<br>
correctly reflected in BZ, is this work that needs to be done?<br>
<br>
> 3. Assign the bug to the committer. This has edge cases, but it's best<br>
> to at least handle the easy ones and then figure out edge cases later.<br>
> The experience is going to be better than what it is right now.<br></blockquote><div><br></div></span><div>Assign the bug to the committer - When? Is it when the first patch set is posted or is it when the patch(es) are merged and bug is moved to MODIFIED?</div><span class=""><div><br></div></span></div></div></blockquote><div> </div><div>This is one good reason for having both bugzilla and github (with label 'Type:Bug') for handling bugs for the project. That way, most of the regular developers can have bugzilla account to post the patch, but for any new developer, posting a patch against github issue, no need for one more account.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Is the above a reference to just the "assigned to", or overall process?<br>
If overall can you elaborate a little more on why this would be better<br>
(I am not saying it is not, attempting to understand how you see it).<br>
<br>
> <br>
> Please provide feedback/comments by end of day Friday. I plan to add<br>
> this activity to the next Infra team sprint that starts on Monday (Sep 17).<br>
<br>
[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1619423" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/<wbr>show_bug.cgi?id=1619423</a><br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br>
</blockquote></span></div></div>
<br>______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>