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

[sankarshan]

On Mon, 17 Feb 2020 at 15:33, Michael Scherer <mscherer at redhat.com> wrote:
>
> Le lundi 17 février 2020 à 09:45 +0530, sankarshan a écrit :
> > There is no meeting planned for 20Feb/Thu
> >
> > On 13Feb we discussed looking at bugzilla.redhat.com --> Github
> > migration.  There are a few OPEN items to consider about this
> >
> > + how to "freeze" the product/component on the bugzilla instance so
> > that no new bugs can be filed. Michael and Deepshikha to get a better
> > understanding of the steps
>
> So I did ask to bugzilla-requests@ (PNT0776283), the answer:
>
> "
> Each product has a field labeled "Open for bug entry" when you uncheck
> the box no one can create new bugs in that product. Anyone with edit
> rights to the product can set this.
>
> This allows you to stop new bugs being created but allows existing bugs
> to work through the pipeline.
>
> We don't like to leave products disabled in the general
> classifications, we move them to the retired classification. This adds
> the following header when someone views a bug in that product:
>
> "This bug is on a product in the Retired classification, you should
> contact the product team outside of Bugzilla before editing this bug as
> it may not be being monitored."
> "
>
> So since that's for product as a whole, we have to decide what to do
> with the components.
>

I would think that we want to retire the entire product/component
chain for the GlusterFS product. This also means that we need to
review and modify any templates etc being used on Github to aid in
better reporting

> I did manually export the list of components from bugzilla to
> https://lite.framacalc.org/9f29-glusterbugzilla
>

This is nifty. Thank you!

@Amar Tumballi - I'd need some help to ensure that I'm doing the
mapping (below) correctly

> So we do have a few that I do not know where to migrate:
> - coreutils

https://github.com/gluster/glusterfs-coreutils

> - doc

https://github.com/gluster/glusterdocs

> - gluster-colonizer

https://github.com/gluster/gluster-colonizer

> - glusterd2

https://github.com/gluster/glusterd2

> - glusterfind
> - gluster-hadoop

https://github.com/gluster/glusterfs-hadoop (?)

> - gluster-hadoop-install
> - HDFS
> - 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)

> - nfs
> - packaging
> - puppet-gluster
> - selinux

https://github.com/gluster/glusterfs-selinux

>
> Some mention a upstream, some look like external repos.
>
> If people have a opinion, please tell me in this thread.
>
>
> > + updating all the NEW and OPEN bugs which will be switched over to
> > Github with a text like "The Gluster project uses Github for
> > reporting
> > of defects; enhancement requests and other items. Please visit the
> > project's Github page". Choosing an appropriate status for the bugs
> > which have been moved over
> >
> > +  a script to undertake the switch. The script would be reviewed by
> > Michael if he has the time. After the meeting Amar posted a link to
> > <https://www.theozimmermann.net/2017/10/bugzilla-to-github/> This
> > post
> > could be a basis for undertaking what we plan to do
> >
> > + setting the plans in motion to switch over to Github from
> > 01Mar2020.
> > This includes updating/modifying any template text which indicates
> > bugzilla.redhat.com to be the preferred workflow and remove any such
> > reference; identity current list of labels and indicate if any
> > additional need to be created; forming a better triage (label and
> > classification process) for the new issues filed on Github



-- 
sankarshan at kadalu.io | TZ: UTC+0530
kadalu.io : Making it easy to provision storage in k8s!