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

Fri Feb 17 16:24:01 UTC 2017

On Thu, 16 Feb 2017 at 06:36, Shyam <srangana at redhat.com> wrote:

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

Personally I am not in favour of moving to 100% github model over bugzilla
as I can form almost any queries out of it. What it gives me a better
tracking ability especially being a maintainer. Until and unless I can do
the same granular things with github as I do for bugzilla, I am not
convinced (Proove me wrong and I do admit that I am a bugzilla expert but
not github!).

I think moving to a github model in maintaining releases and status of
important features is a good step taken, but we should continue to use
bugzilla when it comes to bug fixes.

>
> >
> > 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
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers
>
-- 
- Atin (atinm)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20170217/6904d64a/attachment-0001.html>