On Thu, Feb 9, 2017 at 12:34 AM, Shyam <[email protected]> wrote: > In today's maintainers meeting I wanted to introduce what it would take us > to move away from bugzilla to github. The details are in [1].
<https://hackmd.io/MYUxDYE4BMCYCMC0BGc5aICwFZYDNEBDABniUO2L0nGOUgGZlYg=?view#gluster-github-movement-details> is a well written document. Thank you for the level of detail. I'd like to state that the Gluster project see Bugzilla as a 'defect tracking tool'. For far too long various projects have attempted a number of (often) unsustainable workarounds to extend Bugzilla to be more than a defect tracker. Unfortunately, most cases, it does not work out well for the project. As an established defect tracking tool Bugzilla enables a rich set of methods by which to extract a substantial set of data around reported bugs. There are libraries available (in a couple of programming languages and bindings) to help in extraction and manipulation of the results of the queries. The move to Github lends itself well to project planning. Being able to not only undertake planning for the current release but plan further ahead is an important potential of the 'Projects' model on Github. Thus, features should continue to be on Github. On the other hand, defects/bugs should stay on Bugzilla until sufficient granularity is found on Github to allow 'almost BZ-like' parity. I understand that a large part of the motivation for the move arises from inconsistency in how bugs are cloned or, meta-data around reported bugs are managed. That is possibly more of a reporter hygiene issue which can be solved via template forms; triage by scripts which highlight the flaws; creation of reports/dashboards and working on the results of the query. The Bugzilla based bug lifecycle is well documented with well understood states. I would put forward a hypothesis that a good part of the user base is either familiar with using Bugzilla and/or have scripts that upload log files and such to Bugzilla. The bug lifecycle is also a key element in handling content-under-embargo (as far as I know, Github lacks in this aspect) It would be a good approach to firm up the benefits of feature and project planning in Github before we consider this proposed transition. -- sankarshan mukhopadhyay <https://about.me/sankarshan.mukhopadhyay> _______________________________________________ maintainers mailing list [email protected] http://lists.gluster.org/mailman/listinfo/maintainers
