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

[Niels de Vos]

On Mon, Feb 10, 2020 at 07:55:01PM +0530, sankarshan wrote:
> 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).

If this happens, maintainers and peers working on the components need to
re-introduce a regular bug triage again. Most of the teams working on
different components were self-organizing the triage efforts for a
while. If that is being reduced, or 'forgotten', it needs to be picked
up again.

All maintainers should be subscribed to this list and respond to
messages that are deemed important to them. Discussions about bug triage
for components is definitely an important task that I expect others to
get involved in too.

If this mail thread does not spark the conversation, it may need to be
added as an item to the next community meeting.

> 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 do not really remember how that is done either. We do have a "Gluster
Community" group in Bugzilla, I think. That has been used in the past to
give contrbutors the permission to change state/component/.. of bugs in
the GlusterFS "product". An email to bugzilla-owner at redhat.com with the
request to be added to the group might be sufficient, although I would
not know who could be asked to approve it...

HTH,
Niels


> (*) 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!
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>