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

[Atin Mukherjee]

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).
> 
> QUESTION for #1:
> - Is there any objection if I mass-update many of these bugs to match 
>   their actual status?
> - 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?
+1 for this. I do believe this will definitely help us to reduce the
size of the BZs.

> 
> 
> 
> 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).
This approach could solve this problem, however I would also like to
hear from the list if there is a better approach to do it.

--Atin
> 
> 
> 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?
> 
> Thanks for reading, but responses are more appreciated :)
> 
> Niels
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>