On Mon, 17 Feb 2020 at 15:33, Michael Scherer <msche...@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 -- sankars...@kadalu.io | TZ: UTC+0530 kadalu.io : Making it easy to provision storage in k8s! _______________________________________________ Gluster-infra mailing list Gluster-infra@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-infra