[Gluster-Maintainers] Is the bugs at gluster.org bugzilla account active?

[sankarshan]

On Mon, 10 Feb 2020 at 17:49, Niels de Vos <ndevos at redhat.com> wrote:
>
> On Mon, Feb 10, 2020 at 05:17:26PM +0530, sankarshan wrote:
> > On Mon, 10 Feb 2020 at 15:36, Niels de Vos <ndevos at redhat.com> wrote:
> > >
> > > On Mon, Feb 10, 2020 at 07:25:03AM +0530, sankarshan wrote:
> > > > The default assignee is bugs at gluster.org. I do not often see this
> > > > correctly reassigned to an actual maintainer/developer. Is that
> > > > account active and receives emails?
> > >
> > > This is the mailinglist where all developers working on components for
> > > Gluster should have a filter on the bugzilla headers and triage them.
> > > The current procedure was chosen to prevent single-point of contacts for
> > > a component, and multiple developers (maintainers and peers from the
> > > MAINTAINERS file) are expected to be subscribed to the list.
> > >
> > > - https://lists.gluster.org/mailman/listinfo/bugs
> > > - https://github.com/gluster/glusterdocs/blob/master/docs/Developer-guide/Bugzilla%20Notifications.md
> > > - https://github.com/gluster/glusterdocs/blob/master/docs/Contributors-Guide/Bug-report-Life-Cycle.md
> > >
> > > If this is not followed as expected, component maintainers and peers may
> > > need some refreshing on the procedures. Or we need to adjust the
> > > documentation to a workflow that works better.
> >
> > As far as I can tell one cannot set NEEDINFO on that account (or, it
> > might just be that my account on Red Hat's bugzilla instance lacks
> > that privilege) . Which is a compounded issue when the actual set of
> > developers working on the component do not reassign the reported bug
> > to an individual. I understand the point about decentralization - but
> > at the end of the day, the bugs are mostly to be addressed by an
> > actual human. Not a mailing list alias account.
>
> Assigning the bugs is part of the triage process. Once a bug is traged,
> it should have an owner that answers the questions in any of the
> comments.
>
> There is no use in setting NEEDINFO on a bug that is not assigned yet.
> This is similar to creating an Issue in GitHub, someone needs to triage
> them. It is the responsibility of the whole community to guide
> bugs/questions/.. and make progress. The bugs at gluster.org list just
> makes it easier for regular contributors to stay informed about newly
> reported bugs (and hopefully triage those!).

I understand the triage workflow and the desired outcome. The point I
am making is that if a reported bug continues to go stale in NEW and
assigned to bugs at gluster.org (*), then over a period of time it loses
value (where "value" can be in terms of an actual relevant defect
which was not reviewed and assigned a priority). The desired state is
what is documented in the URLs you have pointed out. The reality is
that since the reported bugs continue to be assigned to a catch-all
alias, it would seem, at least externally, that no one was interested
in planning any future actions on them. The constraints put in place
by the bug reporting system itself - in terms of what users could do
to change meta-data around the reported bugs is another aspect of the
"high floor" when it comes to interactions. I am not sure where it is
documented that a normal account on the bugzilla instance
(bugzilla.redhat.com) can seek to gather rights necessary to make
changes to the status and other specific aspects of a reported bug.

(*) I think the minor difference in how you see things and how I do is
that from your perspective, until a maintainer adds her/his name as
the bug assignee, the bug is not considered to be assigned. I would
think that the fact that a reported bug is posted to the bugs@ list
does raise it to the attention of the individual(s) who are the
maintainers of the component against which it is reported.

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