[CentOS-devel] Platform Tools moving bugs from bugzilla.redhat.com to issues.redhat.com

Wed Aug 23 13:42:16 UTC 2023
Josh Boyer <jwboyer at redhat.com>

On Wed, Aug 23, 2023 at 9:39 AM Neal Gompa <ngompa13 at gmail.com> wrote:
>
> On Wed, Aug 23, 2023 at 9:28 AM Josh Boyer <jwboyer at redhat.com> wrote:
> >
> > On Wed, Aug 23, 2023 at 8:46 AM Neal Gompa <ngompa13 at gmail.com> wrote:
> > >
> > > On Wed, Aug 23, 2023 at 6:51 AM Florian Weimer <fweimer at redhat.com> wrote:
> > > >
> > > > The Red Hat Platform Tools team (who maintain binutils, GCC, gdb, glibc,
> > > > systemtap, valgrind, etc.) have begun to move bugs from
> > > > bugzilla.redhat.com to issues.redhat.com, to the project called “RHEL”.
> > > >
> > > > We'd appreciate if future issues discovered in CentOS Stream were filed
> > > > there directly.  When filing new issues, please make sure that the
> > > > Security Level is set to None, so that others can contribute, and select
> > > > “CentOS Stream” under Projects.  Please do not use the public “CS”
> > > > project for reporting issues in specific RPM packages because we
> > > > (Platform Tools) do not monitor it.  (Compose issues and CentOS Stream
> > > > issues should still be reported in “CS”.)
> > > >
> > >
> > > The Red Hat Jira CS project currently blocks community members from
> > > filing issues or making comments.
> > >
> > > > Community members should be able to create a Red Hat account on
> > > > sso.redhat.com and use that to login to issues.redhat.com.  As far as I
> > > > know, it's not necessary to agree to the Red Hat Enterprise Agreement,
> > > > or any subscription terms.  If that has changed, please let me know.
> > > >
> > >
> > > I don't know this personally, since my account is old and originates
> > > from the JBoss JIRA instance, but I've been told that you are required
> > > now to disclose address and phone number and agree to the RHEA TOS to
> > > access the Jira when you create your account. It would be worth
> > > double-checking this.
> > >
> > > > The user experience should remain largely unchanged, although the
> > > > underlying technology is completely different (Jira vs Bugzilla).  If a
> > > > bug is migrated, a notification is posted to the Bugzilla bug, with
> > > > instructions how to find the migrated issue on issues.redhat.com.  You
> > > > will likely have to re-subscribe to the new issue after migration.  In
> > > > the future, logging into issues.redhat.com from time to time (every few
> > > > weeks or months) will be required to keep receiving notification for
> > > > your bug subscriptions.
> > > >
> > >
> > > Please fix this and don't make accounts go automatically inactive.
> > > That's annoying and painful.
> >
> > To my understanding, this will not be changed.  Inactive accounts are
> > culled to reduce seat license counts.  I believe the cutoff is
> > 90-days.  While I agree it's a change in behavior and somewhat
> > annoying, logging into the instance once a quarter does not seem
> > onerous for someone that wants to actively participate.
> >
>
> It is onerous for people who use CentOS Stream and file bug reports
> waiting for responses given the current lag times. BZes already don't
> get responses for weeks or months in some cases. Even as an active
> participant (if you'd like to count me as one), most of *my* BZes get
> nothing for months. I have no reason to regularly check Jira for my
> issues because there's nothing going on anyway.
>
> It's not "somewhat annoying", it's actually really bad. If you really
> need to worry about seat counts, then adjust the inactivity period to
> align with how long it takes for someone to respond to a ticket.
> Probably one to two years is more appropriate.
>
> I do not think it is reasonable to disable volunteer user/contributor
> accounts like this, especially since it disables your watch lists in
> Jira.

OK.  I will state this more clearly.

You asked to change this.  I inquired if it could be changed
internally.  The answer is no, it cannot.

I'm not trying to justify or argue the merits of the existing
mechanism.  I am trying to set clear expectations so people are aware
of the way it works and can plan accordingly.

josh