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