[Gluster-infra] [Github Migration] Notes and plans from meeting on 13Feb/Thu

[Amar Tumballi]

On Mon, Feb 17, 2020 at 9:53 PM Amar Tumballi <amar at kadalu.io> wrote:

>
>
>
>
>> > I did manually export the list of components from bugzilla to
>> > https://lite.framacalc.org/9f29-glusterbugzilla
>> >
>>
>>
Went through the sheet, and added 2 columns. One for Currently open bugs
for each component. Second, for every 'Gray' (not decided) cell, added
options to migrate. With that data, we need to move 2 bugs to glusterdocs,
and 1 bug for website. Otherwise, 51 bugs are project-infrastructure
related (Its marked green, and I am assuming it will be taken care?). All
other issues gets to glusterfs repo only.

I will fine tune a script I got to pick a given bug, and migrate it to
github. Here is my plan on how we can work on this (writing it again as I
missed some communication before, happy to make changes if one feels).

1. Get a list of open bugs as CSV.
2. Remove 'project-infrastructure' and other 3 bugs mentioned above from
the list.
3. Get a list of remaining OPEN bugs and feed as argument to a script.

  - We can make all this automatic, but I would prefer to have a validation
before hand.

Now what script does:

- pick a bug from the above list:
  * Get complete public-data (I plan to use my ID, so I get only public
information).
  * Feed this to github API.
     - bugzilla.subject + bugzilla.ID ~= github.issue.title
    - bugzilla.description + Bugzilla Link ~= github.issue.body
    - github.issue.labels = [ 'Type:Bug', 'MigratedFromBugzilla' ]
    - github.issue.assignee ~= search_and_map(bugzilla.assignee)
  * Get Github Newly created Issue ID/URL
  * Update the github issue with bugzilla comments and other parameters
like keywords / WhiteBoard etc.
  * Update bugzilla with new github issue link.
  * Update bugzilla status to CLOSED -> UPSTREAM. (Or decide on the
Resolution).


Now, considering we would be CLOSING the bugs in the script itself, if any
bugs got created during this process, we can still get that and feed it to
the same script, after marking bugzilla product not to take new bugs.

Meantime, we need to change github issues template, so if someone goes to
open an issue, it doesn't points to bugzilla :-D I believe the best time to
do this is after running the first round script, and before marking
bugzilla product not to accept new bugs.

Also we have to identify the documents which mention bugzilla workflow, and
change it to Github Issues Workflow, and change them.

Regards,
Amar


This is nifty. Thank you!
>>
>> @Amar Tumballi - I'd need some help to ensure that I'm doing the
>> mapping (below) correctly
>>
>>
> Sure!
>
>
>> > So we do have a few that I do not know where to migrate:
>> > - coreutils
>>
>> https://github.com/gluster/glusterfs-coreutils
>>
>>
> Correct
>
>
>> > - doc
>>
>> https://github.com/gluster/glusterdocs
>>
>>
> Correct (There are few which are part of glusterfs repo itself like
> manpages, but I guess we can cross link the issues within the org).
>
>
>
>> > - gluster-colonizer
>>
>> https://github.com/gluster/gluster-colonizer
>>
>>
> Correct
>
>
>> > - glusterd2
>>
>> https://github.com/gluster/glusterd2
>>
>>
> Correct. But Ideally, if there is anything OPEN, we can close it with
> WONTFIX.
>
>
>
>> > - glusterfind
>>
>
> This is part of glusterfs repo itself -
> https://github.com/gluster/glusterfs/tree/master/tools/glusterfind
>
>
>
>> > - gluster-hadoop
>>
>> https://github.com/gluster/glusterfs-hadoop (?)
>>
>>
> Correct. Again, if there is anything OPEN, we can close them with WONTFIX.
>
>
>
>> > - gluster-hadoop-install
>> > - HDFS
>>
>
> All hadoop can be mapped to the same above repo, but again, we can close
> them all.
>
>
>> > - nagios
>>
>> https://github.com/gluster/nagios-server-addons
>> https://github.com/gluster/gluster-nagios-common
>> https://github.com/gluster/gluster-nagios-addons
>>
>> (I'm not sure which of the above is appropriate)
>>
>
> I would pick `gluster-nagios-common`.
>
>
>>
>> > - nfs
>>
>
> I would like to believe these are 'gNFS', which means, it is part of
> glusterfs.
>
>
>
>> > - packaging
>>
>
> While there are 2 repos (glusterfs-debian, glusterfs-SUSE), I would like
> to keep this as part of glusterfs itself, for now.
>
>
>> > - puppet-gluster
>>
>
> All bugs which are OPEN can get CLOSED (WONTFIX/TIMEOUT).
>
>
>> > - selinux
>>
>> https://github.com/gluster/glusterfs-selinux
>>
>>
> Correct
>
>
>> >
>> > Some mention a upstream, some look like external repos.
>> >
>> > If people have a opinion, please tell me in this thread.
>> >
>> >
>
>
> Looks like I am not part of gluster-infra ML. Hence missed some of these
> conversations. Joining now.
>
> -Amar
>


-- 
--
https://kadalu.io
Container Storage made easy!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-infra/attachments/20200217/6a0103da/attachment.html>