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

[Amye Scavarda]

On Wed, Feb 8, 2017 at 11:04 AM, Shyam <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
> 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.

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.

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 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.)

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?

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

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?

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.
Thanks!
- amye

-- 
Amye Scavarda | amye at redhat.com | Gluster Community Lead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170215/acd576c5/attachment-0001.html>