Re: [Gluster-devel] Changing a bug's status related to patches in Gerrit and/or git-tags?

[Lalatendu Mohanty]

On 04/10/2014 04:22 PM, Niels de Vos wrote:
> Hi all,
>
> recently we have started to document the "Bug report life cycle"
> (http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle).
> The document contains quite some actions that are needed by engineers
> and reporters. There does not seem to be any existing gatekeeper to
> validate the procedures from the document.
>
> This email contains two points on which I would like to hear your
> opinions:
>
> 1. how to do recurring review of open bugs, and correct their status
> 2. should there be one bug per version/release to accommodate better
>     tracking
>
>
> For 1:
>
> Now, last weekend I've been looking into getting a summary of open
> Gluster bugs in bugzilla, match them with patches posted in Gerrit and
> check in a git repository if there has been a tagged release with those
> changes. The result is a rather rough Python script that handles all
> this and returns a complete summary. Some random examples:
>
> #1032894 ON_QA      - Anand Avati - spurious ENOENTs when using libgfapi
>    [master] I635fc0 cluster/afr: Remove stale index in self-heal codepath (NEW)
>    [release-3.4] I0909f2 Revert "core: fix errno for non-existent GFID" (MERGED)
>    [release-3.4] I38b72f tests: Don't use stripe-replicate volume in 
> bug-905864.t (MERGED)
>    [release-3.4] I74818a cluster/dht: interim fix for reverting 837422858c 
> (MERGED)
>    [master] Ib255b9 dht: handle ESTALE/ENOENT in dht_access (MERGED)
>    [release-3.4] I7a06ea core: fix errno for non-existent GFID (MERGED)
>    ** Bug should be in POST, change I635fc0 is not merged yet **
>
> #1036102 ON_QA      - Kaleb KEITHLEY - glusterfsd: memory leak in 
> glusterfs_volfile_fetch()
>    [release-3.4] I8f3117 glusterfsd: fix small memory leaks in 
> glusterfsd-mgmt.c (MERGED)
>    [release-3.5] Id3f813 glusterfsd: fix small memory leaks in 
> glusterfsd-mgmt.c (MERGED)
>    [master] Ic306d6 glusterfsd: fix small memory leaks in glusterfsd-mgmt.c 
> (MERGED)
>    ** Bug should be CLOSED, v3.4.3 contains a fix **
>
> #1048188 POST       - krishnan parthasarathi - socket doesn't notify disconnect 
> due to packet drop, simulated using iptables, to higher layers
>    [master] I1d3f32 socket: propogate connect failure in socket_event_handler 
> (MERGED)
>    ** Change I1d3f32 has been merged, but bug is not in MODIFIED **
>
> #1071504 MODIFIED   - Justin Clift - rpmbuild/BUILD directory needs to be 
> created for CentOS 5.x
>    [release-3.5] I2cd6ca build: Add missing rpmbuild/BUILD dir for CentOS 5.x 
> (MERGED)
>    [master] I90ad70 build: Add missing rpmbuild/BUILD dir for CentOS 5.x 
> (MERGED)
>    ** Bug should be ON_QA, use v3.5.0beta5 for verification of the fix **
>
> There are currently 265 bugs in POST, MODIFIED and ON_QA that get
> detected with my script. I did not check other statuses yet, but that is
> easy enough to do. For most of these bugs it is pretty clear what their
> actual status should be. Changing the status, setting a "Fixed in
> version" can mostly be automated with the "bugzilla" command (part of
> the "python-bugzilla" package).

Excellent work!!

> QUESTION for #1:
> - Is there any objection if I mass-update many of these bugs to match
>    their actual status?

I am in for mass-update at this point of time. Because we have hundreds 
of bugs and it would be logical to update them through scripts.

> - After the list has been reduced to a smaller number of bugs, should
>    there be a nag-email every week about bugs in an unexpected status?

Should be fine.

> For 2:
>
> There are some difficulties with bugs that have patches for different
> release branches. Some branches could have a release (like 3.4) already,
> and are in beta for an other (3.5). These bugs seem to have an internal
> conflict. It also makes it very difficult for users to track what
> version contains a fix.
>
> QUESTION for #2:
> - Shall we change the "Bug report life cycle" and advise to file
>    separate bugs per release? This makes it easier to track changes in
>    master (should go to MODIFIED), and copy/clone bugs for releases that
>    users are interested in (well, or copy the other way around, that does
>    not really matter).

IMO it is not right to ask the user to file separate bugs per release, 
because most of the time users just use one version of glusterfs and 
there is high probability that they don't know if the bug exists in 
other releases. But when developer fix the bug, he/she can track if the 
code (which is causing the issue) is present in other releases as well. 
So developer should fork the bug for other releases and use the release 
specific bugs for the patch.

> And, one last thing... Of course I'd like to make the script available
> for others too. However, I'm sure there must be some scripts that
> interact with Bugzilla (like the Gerrit "patch has been posted" one).
> Putting all these scripts in one location would likely be a good idea.
> In future it might even be wanted to automatically update the status of
> bugs when a git-tag is pushed the to repository / release is done. So,
> where to place these kind of scripts?

Should we create a forge project for this?

> Thanks for reading, but responses are more appreciated :)
>
> Niels
>
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel