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

[Niels de Vos]

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?



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).


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