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

Mon Feb 20 05:55:06 UTC 2017

regards
Aravinda

On 02/17/2017 08:46 PM, Shyam wrote:
> 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?
I will take up this task.

>
>>  - 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/
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> http://lists.gluster.org/mailman/listinfo/maintainers