On Thu, 2022-03-10 at 09:44 -0500, Colin Walters wrote: > > On Mon, Mar 7, 2022, at 12:44 PM, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux > > release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > I think it's unfortunate to replace the FOSS Bugzilla with > proprietary software. I am eternally conflicted about this with > respect to GitHub (xref > https://blog.verbum.org/2020/12/03/still-on-github/ ) but...Jira is > not as compelling of a user experience upgrade. > > A continual challenge related to this I feel is using the same > software to track product bugs with potentially sensitive customer > data in it, and public open development. > > To link these things, I quite commonly move Bugzilla discussion that > has no need to be private to Github, because I know Github is always > public (from our PoV). > > One thing that may help is to at least use different themes (e.g. > blue colors for public CentOS issues, red for RHEL?) on > issues.redhat.com. > > Long term if Bugzilla slowly morphs into only being used by Fedora, > personally I'd prefer to have bugs/issues in gitlab instead. Given how we use bugzilla (we do not really use any big feature there) in Fedora I would give a big +1 to use an issue tracker embedded in the forge we use to store the packages (whether that is pagure, gitlab, github, or something else). Also I always resented that I need two separate accounts to deal with Fedora packages, I think reducing that to host all in the same place with the same authentication will also be a positive factor in fostering collaboration, less barriers. It will also reduce administrative overhead of having to configure components/ownership/etc in multiple places and what not. Finally by having issues and code in the same place it means we can easily connect commits/PRs/MRs to the issues meaning our issue tracker a lot more useful, and will allow us to have better content also in our updates, where today associating an update to an issue (a bz) is not happening as well as it could. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
