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

[Shyam]

On 02/15/2017 04:27 PM, Amye Scavarda wrote:
> On Wed, Feb 8, 2017 at 11:04 AM, Shyam <srangana at redhat.com
> <mailto:srangana at redhat.com>> wrote:
>
>     Hi,
>
>     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].
>
>     Further to this, below is a mail detailing the plan(s) and attention
>     needed to make this happen. Further I am setting up a maintainer
>     meet on Friday 10th Feb, 2017, to discuss this plan and also discuss,
>     - Focus areas: ownership and responsibility
>     - Backlog population into github
>
>     Request that maintainers attend this, as without a quorum we
>     *cannot* make this move. If you are unable to attend, the please let
>     us know any feedback on these plans that we need to consider.
>
>     Calendar and plans for moving away from bugzilla to gihub:
>     1) Arrive maintainer consensus on the move
>       - 15th Feb, 2017
>       - This would require understanding [1] and figuring out if all
>     requirements are considered
>       - We will be discussing [1] in detail on the coming Friday.
>
>     2) Announce plans to the larger development and user community for
>     consensus
>       - Close consensus by 22nd Feb, 2017
>
>     3) (request and) Work with Infra folks for worker ant like
>     integration to github instead of bugzilla
>       - Date TBD (done in parallel from the beginning)
>
>     <<Assuming we are able to get (3) done by 24th Feb>>
>
>     4) Announce migration plans to larger community, calling out a 2
>     week window, after which bugzilla will be closed (available for
>     historical reasons), and gerrit will also not accept bug IDs for changes
>       - 27th Feb, 2017
>
>     5) Close bugzilla and update gerrit as needed
>       - 10th Feb, 2017 weekend
>
>     6) Go live on the weekend specified in (5)
>
>     Shyam
>     [1] http://bit.ly/2kIoFJf
>     _______________________________________________
>     maintainers mailing list
>     maintainers at gluster.org <mailto:maintainers at gluster.org>
>     http://lists.gluster.org/mailman/listinfo/maintainers
>     <http://lists.gluster.org/mailman/listinfo/maintainers>
>
>
>
> I don't see a ton of followup around this issue here, and we should have
> this conversation in -devel as well. I feel like it's gotten lost in
> Winter Conference Season.
>
> That being said, here's my take: this seems hasty and doing this in a
> few weeks seems like asking for trouble.
>
> Bugzilla has a number of features that we're currently using, and some
> that we're really going to need as a project. Being able to have a
> feature that whines at you if you haven't touched an issue in some time?
> Helpful.

So, BZ features we (myself and a few others) considered most of what we 
use (clones, release tracker, keywords etc.). Yes, there are folks who 
may have setup whines and other such, but we will lose that.

We need people to speak up on what they may lose or what they want, so 
that we can evaluate it.

>
> Bugzilla also has some features that we, as a project, are going to
> need, even if we don't think we need them right now.

Bugzilla is much more than github issues will ever be, the question is 
can we live with github, possibly not the other way around.

I would say we (as in maintainers) agreed to living with github, now we 
need to realize the limitations (if any).

>
> How does Github help a project with something like a zero-day issue that
> needs to be fixed but can't be public?
> Or other security issues?

Does a security at gluster.org like list help here? People who are 
reporting security vulnerabilities are also responsible not to make it 
public (I think), so reaching out to a mailing list that is more 
strictly controlled may help here?

How is this handled in Redhat Bugzilla for upstream/opensource projects? 
That may help arriving at solutions to the problem.

> Does the current github workflow make sense? What other features are
> they likely to add in the future? What happens if they take it away?
> We're at their mercy. (Which is fine if we decide that, but we need to
> choose.)

Does the current workflow make sense? Only others need to answer :) 
unfortunately, having created most of it, it does to me.

I thought, for the last part in the above statement, we decided in the 
maintainer meetings, that it is fine to be at their (github) mercy (not 
in the same words), but yes we are.

>
> In the not too distant past, Github was considered another company (and
> not critical infrastructure like it is now) and like all companies,
> liable to fail, change the product or do something that we might not
> like. What's our plan for mitigating this risk?

Export the data out, and import it somewhere else, not much else we can 
do here.

>
> I would rather us work through another release cycle evaluating Github
> that has more contributors and more people weighing in.

I would say we need folks to look at this and respond, A release is not 
needed to evaluate the same.

I am prototyping this at [1] and using gerrit-stage as well [2] (thanks 
to Nigel for the infra help here). This example may additionally help 
people understand this?

>
> This isn't a decision we can make in haste -  we don't know the level of
> effort to move, if our infra team even has the space right now for this
> project, and what benefits we get out of it. What would be a rollback
> plan for something of this magnitude?

Hmmm... I would let the infra folks comment here. My understanding is 
that the one major entity that changes here is WorkerAnt, that posts 
today to Bugzilla and needs to post to github instead. Also, the jenkins 
bugcompare job needs to change to ensure it compares against issues. 
Other than these nothing else should need a change from the infra 
perspective (of course we need to look deeper here).

>
> Please sell me on this, I invite all the sales pitches, and I am sorry
> that I have a bunch of pointed questions - but we need to think these
> things through.

Absolutely, that is the intention of taking it through maintainers 
before releasing this to the world.

> Thanks!
> - amye

[1] https://github.com/gluster/test/issues/6

[2] https://gerrit-stage.rht.gluster.org/#/q/project:gluster-test