Hi Naga, a while back you closed a bunch of bugs that roughly matched this criteria: - select mainline bug to potentially close - is there a cloned bug to a stable release (backport) - is the backport marked as CLOSED/CURRENTRELEASE -> close the mainline bug as CLOSED/NEXTRELEASE (from http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12760/focus=12888 ) Most of this looks fine, except that we can not use the "cloned" field. There are bugs that get filed against different versions, and then get marked as "depends on" or "blocks". Filing bugs through cloning is only one option, and misses the other bugs. We really would need to use those other fields instead. If you are interested in this, you could help us by defining the policy to close mainline bugs. The current policy is documented here: http://gluster.readthedocs.org/en/latest/Contributors-Guide/Bug-report-Life-Cycle/ Could you send a pull request with an updated text? Also, can you share the script or bugzilla search query that you used to identify the bugs that you closed? It is something that we would need to run after each release is made. A note should get added to the release process: http://gluster.readthedocs.org/en/latest/Contributors-Guide/GlusterFS-Release-process/ A pull request with the script that you used can be sent to our release-tools repository on GitHub: https://github.com/gluster/release-tools We have some developers that are (slowly) working on automating the bug status when patches get posted, merged and releases are tagged. Once they have some advancement in their project, we can integrate your close-mainline-bugs script too. Many thanks, Niels
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
