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

[Shyam]

On 02/17/2017 08:14 AM, Niels de Vos wrote:
> 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].
>
> Unfortunately I could not join the meeting. Could you share the
> recording?

Vijay owns the meeting, so if there is a recording he would have it.

Basically we decided to fork it to another meeting, just to focus on 
this topic, and that (10th Feb) meeting was a no show, hence all that 
you have is this mail and the document that I attached with it.

>
> From the document there are at least a few things missing:

Thank you, this is exactly what we need, i.e what is missing, and 
how/who can help moving these forward.

I have created a bug to track what needs to change to adapt to github 
here [5], would appreciate it if this list is added there as well.

>  - what about http://bugs.cloud.gluster.org/ for tracking?

Well, it has to change to use github issues for one. Who can help here?

>  - who is going to update the release-tools [2] scripts?

I see 3 contributors to release-tools, Kaushal, Raghu and yourself. Can 
any of you help?

More generically, we would be relying on github APIs [7] to pull parts 
of this off.

>  - can we create trackers that are not for a release, but for certain
>    features that gets partially implemented over releases?

I would need a more concrete example here. For example will the tracker 
issue # be used in gerrit when committing changes, or individual issues? 
If individual issues, then it is fine, the tracker can refer other 
issues as needed. But, possibly this is not what you are looking for, an 
example would be better.

>  - email notifications like [3]?

I just created one for myself yesterday, which was "List-ID = 
gluster/glusterfs <glusterfs.gluster.github.com>"

So we can create this on a per repo granularity. More advanced filters 
will need mail header study. Is that something we need before a roll out 
though?

>  - rewrite of the bug triage procedures from [4]

Yes, we need help here.

>  - we have many components in bugzilla, how is this done in GitHub?

Using labels, see [6].

>
>> 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.
>
> Did this take place? If so, some more details and sharing of the chat
> logs would be nice (or recording of the session?).

No, see above on no show.

>
>> 2) Announce plans to the larger development and user community for consensus
>>   - Close consensus by 22nd Feb, 2017
>
> Wow, that is pretty quick...

Well we have been talking about this for more than 2 months now, in the 
maintainers forum. Also, some level of study on github and how to make 
it a BZ replacement is done. What remains is to act, what do you think 
the time line should be, to close consensus?

>
>> 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
>
> We can not close bugzilla for all components. Some projects under the
> GlusterFS Community project are maintained outside of the main glusterfs
> repository. It is up to the maintainers of those projects to choose
> where they wan t bugs reported. glusterfs-coreutils is one, and I'm
> pretty sure there are others.

This change is for glusterfs repository only. Maybe I should call that 
out more clearly (the mail subject could be misleading).

>
>> 5) Close bugzilla and update gerrit as needed
>>   - 10th Feb, 2017 weekend
>
> This must be an incorrect date?

Yes, that was intended as 10th March.

But in reality this calendar is shot to hell at the moment, considering 
we are getting feedback very slowly.

>
>> 6) Go live on the weekend specified in (5)
>>
>> Shyam
>> [1] http://bit.ly/2kIoFJf
> [2] https://github.com/gluster/release-tools
> [3] https://github.com/gluster/glusterdocs/blob/master/Developer-guide/Bugzilla%20Notifications.md
> [4] http://gluster.readthedocs.io/en/latest/Contributors-Guide/Bug-Triage/
[5] Bug to track things that need to change for github based workflow: 
https://bugzilla.redhat.com/show_bug.cgi?id=1423002
[6] github glusterfs labels mail: 
http://lists.gluster.org/pipermail/maintainers/2016-November/001726.html
[7] github API: https://developer.github.com/v3/