[Gluster-Maintainers] Move out of bugzilla to github issues --> for everything...

[Sankarshan Mukhopadhyay]

On Thu, Feb 9, 2017 at 12:34 AM, Shyam <srangana at redhat.com> 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>