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