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

[Amar Tumballi]

On Tue, Sep 11, 2018 at 9:25 PM, Atin Mukherjee <amukherj at redhat.com> wrote:

>
>
> On Mon, Sep 10, 2018 at 7:09 PM Shyam Ranganathan <srangana at redhat.com>
> wrote:
>
>> On 09/10/2018 08:37 AM, Nigel Babu wrote:
>> > Hello folks,
>> >
>> > We now have review.gluster.org <http://review.gluster.org> as an
>> > external tracker on Bugzilla. Our current automation when there is a
>> > bugzilla attached to a patch is as follows:
>> >
>> > 1. When a new patchset has "Fixes: bz#1234" or "Updates: bz#1234", we
>> > will post a comment to the bug with a link to the patch and change the
>> > status to POST. 2. When the patchset is merged, if the commit said
>> > "Fixes", we move the status to MODIFIED.
>> >
>> > I'd like to propose the following improvements:
>> > 1. Add the Gerrit URL as an external tracker to the bug.
>>
>> My assumption here is that for each patch that mentions a BZ, an
>> additional tracker would be added to the tracker list, right?
>>
>> Further assumption (as I have not used trackers before) is that this
>> would reduce noise as comments in the bug itself, right?
>>
>> 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.
>>
>
> 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.
>
>
>> > 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?
>>
>> > 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.
>>
>
> 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?
>
>
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.



>
>> 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).
>>
>> >
>> > 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
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180911/df92b1e1/attachment-0001.html>