On 04/10/2014 04:22 PM, Niels de Vos wrote:
Hi all,

recently we have started to document the "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

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

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 
   [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 
   [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 
   ** 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 
   ** 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 
   [master] I90ad70 build: Add missing rpmbuild/BUILD dir for CentOS 5.x 
   ** 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 :)


Gluster-devel mailing list

Gluster-devel mailing list

Reply via email to