On 02/20/2017 01:37 AM, Nigel Babu wrote:
Hello,
I have had concerns about this move for a while. Michael and I are not official
maintainers of Gluster, but implicitly, we maintain infrastructure for Gluster
and I have opinions to add from that point of view. We've already published our
[infra plans for 2017][1]. Having such a large change obviously impacts our
plans. My opposition to this plan is from the point of view of "Is it worth
it?".
I believe this is worth it, it simplifies our development workflow,
gives us the ability to project our longer term plans more effectively,
and lowers the entry barrier for users to participate in our community.
Further, it also puts back more focus on maintainers and github
collaborators to be active upstream, thereby creating a more inclusive
upstream than what we have currently.
* Is it worth changing practically all our scripts and workflow to move to
GitHub? Any move will create even more work for the project in terms of work
the infra team has to do.
I/we are willing to share/do the work here, if we decide to take the plunge!
* What about people who use the features of bugzilla not in Github issues? For
example, whine. It's a very important for feature for those who want to
triage bugs on time. Yes, we can write hacks, but that further leads to "Is
it worth it"?
We get some we lose some features, like I already stated, I do
understand github issues are not a bugzilla replacement. Bugzilla has
far more features than github, so we can never be the same.
What are we willing to lose? Whine has come up before, but no one (in
maintainers till now) has spoken up about absolutely needing it.
Mail headers have come up, but again I do not hear a big "no" because
some headers are not supported.
Triage has been brought up, I would really like to hear/see how that
query can change from others?
The bugzilla feature richness debate, will really come down to what we
can live with, and what others cannot live with. I do not see this as a
deciding factor in the move, unless we are losing something that is
mandatory to have and we need (are yet?) to surface that.
* Storage for log files and cores is a story we haven't sorted out yet. We will
need to re-invent the wheel in terms of a hosting service for these files
(more work).
I think I mentioned keeping BZ open for this as part of the solution,
and it seems like no further work is required in that case. Does that
not make a solution for this problem?
* This is also going to create more work downstream. I bet we have scripts and
queries written based on bugzilla. We could argue that we don't have to care
about downstream, but if we had a [RACI][2], they'd be under "consulted" or
at least "informed".
Yes, Michael raised this point, and this is something we need to close
before we decide to roll-out (or continue this conversation?) (IOW,
there is consultation to be done here and that will be done).
* Have we had conversations with projects of Ansible who do use Github for
their pain points? I'm curious to see if we have any learnings. Michael has
mentioned that the Github bot that Ansible folks use runs into Github's API
limits. I'm reasonably sure we'd run into the same problem.
I learned about this a couple of days back, so to answer, no we have not
reached out to Ansible folks yet, but we will (once we are sure what we
want for the *present*, i.e within 2 weeks as 3.11 scope (and possibly
4.0 scope) will roll out by then).
IOW, if this is the only blocker for this proposal, then I will do that
ASAP, else I would focus on how to get features completely tracked in
github and worry about bugs and talking to other communities later.
* The document discusses security bugs going into bugzilla. How do we make it
less confusing for someone filing a bug. What about a bug file which later is
found to be a security bug? How do we address that?
For the former, we will make it easier by calling this out in the github
issue template that we will put up (for reference see [3]). For the
latter, how does bugzilla handle this today?
FTR, over the course of this conversation is when we have (re)discovered
how we handle security issues using bugzilla, so more data there would help.
* If our goal is to make things simpler, we're actually moving in the opposite
direction. Issues can be disabled or enabled. Pull requests cannot. It's not
often that a project uses Github issues for bug tracking and does not use
pull requests. That is confusing to *me*.
That is true, that *most* projects do often use PRs (almost) first.
Unfortunately, PRs do not give us what we want in terms of reviews, so
maybe another day.
But I would still argue, that this does not move things in the opposite
direction. Surely, taking one tool (bugzilla) away from the chain does
not do that?
In terms of clarity and not confusing people I would again refer to [3]
which should help people understand that we do not take PRs at the
moment, and also guide them, at the first opportunity, to use our gerrit
instance instead.
These is not a conclusive list, but this much already has me convinced that the
move is **NOT** worth it. In fact, it will cause enough fires to keep us busy
for 3 to 4 months needlessly. We have enough pieces to work on without adding
new fires.
I would like a conclusive list (as much as possible, i.e, not stating
"say everything that you can think of now and say no more later!"), else
we are dooming this for eternity. A conclusive list helps take this up
in the future once the issues raised are adequately addressed.
[1]: http://lists.gluster.org/pipermail/gluster-infra/2017-February/003194.html
[2]: https://en.wikipedia.org/wiki/Responsibility_assignment_matrix
[3] github templates: https://review.gluster.org/16618
--
nigelb
On Wed, Feb 08, 2017 at 02:04:07PM -0500, Shyam 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
[email protected]
http://lists.gluster.org/mailman/listinfo/maintainers
