<div><br><div class="gmail_quote"><div>On Thu, 16 Feb 2017 at 06:36, Shyam <<a href="mailto:srangana@redhat.com">srangana@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/15/2017 04:27 PM, Amye Scavarda wrote:<br class="gmail_msg">
> On Wed, Feb 8, 2017 at 11:04 AM, Shyam <<a href="mailto:srangana@redhat.com" class="gmail_msg" target="_blank">srangana@redhat.com</a><br class="gmail_msg">
> <mailto:<a href="mailto:srangana@redhat.com" class="gmail_msg" target="_blank">srangana@redhat.com</a>>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hi,<br class="gmail_msg">
><br class="gmail_msg">
> In today's maintainers meeting I wanted to introduce what it would<br class="gmail_msg">
> take us to move away from bugzilla to github. The details are in [1].<br class="gmail_msg">
><br class="gmail_msg">
> Further to this, below is a mail detailing the plan(s) and attention<br class="gmail_msg">
> needed to make this happen. Further I am setting up a maintainer<br class="gmail_msg">
> meet on Friday 10th Feb, 2017, to discuss this plan and also discuss,<br class="gmail_msg">
> - Focus areas: ownership and responsibility<br class="gmail_msg">
> - Backlog population into github<br class="gmail_msg">
><br class="gmail_msg">
> Request that maintainers attend this, as without a quorum we<br class="gmail_msg">
> *cannot* make this move. If you are unable to attend, the please let<br class="gmail_msg">
> us know any feedback on these plans that we need to consider.<br class="gmail_msg">
><br class="gmail_msg">
> Calendar and plans for moving away from bugzilla to gihub:<br class="gmail_msg">
> 1) Arrive maintainer consensus on the move<br class="gmail_msg">
> - 15th Feb, 2017<br class="gmail_msg">
> - This would require understanding [1] and figuring out if all<br class="gmail_msg">
> requirements are considered<br class="gmail_msg">
> - We will be discussing [1] in detail on the coming Friday.<br class="gmail_msg">
><br class="gmail_msg">
> 2) Announce plans to the larger development and user community for<br class="gmail_msg">
> consensus<br class="gmail_msg">
> - Close consensus by 22nd Feb, 2017<br class="gmail_msg">
><br class="gmail_msg">
> 3) (request and) Work with Infra folks for worker ant like<br class="gmail_msg">
> integration to github instead of bugzilla<br class="gmail_msg">
> - Date TBD (done in parallel from the beginning)<br class="gmail_msg">
><br class="gmail_msg">
> <<Assuming we are able to get (3) done by 24th Feb>><br class="gmail_msg">
><br class="gmail_msg">
> 4) Announce migration plans to larger community, calling out a 2<br class="gmail_msg">
> week window, after which bugzilla will be closed (available for<br class="gmail_msg">
> historical reasons), and gerrit will also not accept bug IDs for changes<br class="gmail_msg">
> - 27th Feb, 2017<br class="gmail_msg">
><br class="gmail_msg">
> 5) Close bugzilla and update gerrit as needed<br class="gmail_msg">
> - 10th Feb, 2017 weekend<br class="gmail_msg">
><br class="gmail_msg">
> 6) Go live on the weekend specified in (5)<br class="gmail_msg">
><br class="gmail_msg">
> Shyam<br class="gmail_msg">
> [1] <a href="http://bit.ly/2kIoFJf" rel="noreferrer" class="gmail_msg" target="_blank">http://bit.ly/2kIoFJf</a><br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> maintainers mailing list<br class="gmail_msg">
> <a href="mailto:maintainers@gluster.org" class="gmail_msg" target="_blank">maintainers@gluster.org</a> <mailto:<a href="mailto:maintainers@gluster.org" class="gmail_msg" target="_blank">maintainers@gluster.org</a>><br class="gmail_msg">
> <a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.gluster.org/mailman/listinfo/maintainers</a><br class="gmail_msg">
> <<a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.gluster.org/mailman/listinfo/maintainers</a>><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> I don't see a ton of followup around this issue here, and we should have<br class="gmail_msg">
> this conversation in -devel as well. I feel like it's gotten lost in<br class="gmail_msg">
> Winter Conference Season.<br class="gmail_msg">
><br class="gmail_msg">
> That being said, here's my take: this seems hasty and doing this in a<br class="gmail_msg">
> few weeks seems like asking for trouble.<br class="gmail_msg">
><br class="gmail_msg">
> Bugzilla has a number of features that we're currently using, and some<br class="gmail_msg">
> that we're really going to need as a project. Being able to have a<br class="gmail_msg">
> feature that whines at you if you haven't touched an issue in some time?<br class="gmail_msg">
> Helpful.<br class="gmail_msg">
<br class="gmail_msg">
So, BZ features we (myself and a few others) considered most of what we<br class="gmail_msg">
use (clones, release tracker, keywords etc.). Yes, there are folks who<br class="gmail_msg">
may have setup whines and other such, but we will lose that.<br class="gmail_msg">
<br class="gmail_msg">
We need people to speak up on what they may lose or what they want, so<br class="gmail_msg">
that we can evaluate it.</blockquote><div><br></div><div>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!).</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Bugzilla also has some features that we, as a project, are going to<br class="gmail_msg">
> need, even if we don't think we need them right now.<br class="gmail_msg">
<br class="gmail_msg">
Bugzilla is much more than github issues will ever be, the question is<br class="gmail_msg">
can we live with github, possibly not the other way around.<br class="gmail_msg">
<br class="gmail_msg">
I would say we (as in maintainers) agreed to living with github, now we<br class="gmail_msg">
need to realize the limitations (if any).<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> How does Github help a project with something like a zero-day issue that<br class="gmail_msg">
> needs to be fixed but can't be public?<br class="gmail_msg">
> Or other security issues?<br class="gmail_msg">
<br class="gmail_msg">
Does a <a href="mailto:security@gluster.org" class="gmail_msg" target="_blank">security@gluster.org</a> like list help here? People who are<br class="gmail_msg">
reporting security vulnerabilities are also responsible not to make it<br class="gmail_msg">
public (I think), so reaching out to a mailing list that is more<br class="gmail_msg">
strictly controlled may help here?<br class="gmail_msg">
<br class="gmail_msg">
How is this handled in Redhat Bugzilla for upstream/opensource projects?<br class="gmail_msg">
That may help arriving at solutions to the problem.<br class="gmail_msg">
<br class="gmail_msg">
> Does the current github workflow make sense? What other features are<br class="gmail_msg">
> they likely to add in the future? What happens if they take it away?<br class="gmail_msg">
> We're at their mercy. (Which is fine if we decide that, but we need to<br class="gmail_msg">
> choose.)<br class="gmail_msg">
<br class="gmail_msg">
Does the current workflow make sense? Only others need to answer :)<br class="gmail_msg">
unfortunately, having created most of it, it does to me.<br class="gmail_msg">
<br class="gmail_msg">
I thought, for the last part in the above statement, we decided in the<br class="gmail_msg">
maintainer meetings, that it is fine to be at their (github) mercy (not<br class="gmail_msg">
in the same words), but yes we are.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> In the not too distant past, Github was considered another company (and<br class="gmail_msg">
> not critical infrastructure like it is now) and like all companies,<br class="gmail_msg">
> liable to fail, change the product or do something that we might not<br class="gmail_msg">
> like. What's our plan for mitigating this risk?<br class="gmail_msg">
<br class="gmail_msg">
Export the data out, and import it somewhere else, not much else we can<br class="gmail_msg">
do here.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> I would rather us work through another release cycle evaluating Github<br class="gmail_msg">
> that has more contributors and more people weighing in.<br class="gmail_msg">
<br class="gmail_msg">
I would say we need folks to look at this and respond, A release is not<br class="gmail_msg">
needed to evaluate the same.<br class="gmail_msg">
<br class="gmail_msg">
I am prototyping this at [1] and using gerrit-stage as well [2] (thanks<br class="gmail_msg">
to Nigel for the infra help here). This example may additionally help<br class="gmail_msg">
people understand this?<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> This isn't a decision we can make in haste - we don't know the level of<br class="gmail_msg">
> effort to move, if our infra team even has the space right now for this<br class="gmail_msg">
> project, and what benefits we get out of it. What would be a rollback<br class="gmail_msg">
> plan for something of this magnitude?<br class="gmail_msg">
<br class="gmail_msg">
Hmmm... I would let the infra folks comment here. My understanding is<br class="gmail_msg">
that the one major entity that changes here is WorkerAnt, that posts<br class="gmail_msg">
today to Bugzilla and needs to post to github instead. Also, the jenkins<br class="gmail_msg">
bugcompare job needs to change to ensure it compares against issues.<br class="gmail_msg">
Other than these nothing else should need a change from the infra<br class="gmail_msg">
perspective (of course we need to look deeper here).<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Please sell me on this, I invite all the sales pitches, and I am sorry<br class="gmail_msg">
> that I have a bunch of pointed questions - but we need to think these<br class="gmail_msg">
> things through.<br class="gmail_msg">
<br class="gmail_msg">
Absolutely, that is the intention of taking it through maintainers<br class="gmail_msg">
before releasing this to the world.<br class="gmail_msg">
<br class="gmail_msg">
> Thanks!<br class="gmail_msg">
> - amye<br class="gmail_msg">
<br class="gmail_msg">
[1] <a href="https://github.com/gluster/test/issues/6" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/gluster/test/issues/6</a><br class="gmail_msg">
<br class="gmail_msg">
[2] <a href="https://gerrit-stage.rht.gluster.org/#/q/project:gluster-test" rel="noreferrer" class="gmail_msg" target="_blank">https://gerrit-stage.rht.gluster.org/#/q/project:gluster-test</a><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
maintainers mailing list<br class="gmail_msg">
<a href="mailto:maintainers@gluster.org" class="gmail_msg" target="_blank">maintainers@gluster.org</a><br class="gmail_msg">
<a href="http://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.gluster.org/mailman/listinfo/maintainers</a><br class="gmail_msg">
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature">- Atin (atinm)</div>