Maintainer preferred method of blocker bug notification?

[Chris Murphy]

Hi,

At a recent QA meeting I raised the idea of a better way for
maintainers to find out when their package is a release blocking bug.
Better is vaguely defined by me as: not email based, and not adamw
based (Adam Williamson is in fact a person not a bot).

Currently, the ways a maintainer finds out a bug is release blocking:

1. Bugzilla email. When QA determines a bug is a blocker, it's noted
in the bug as a comment, and bugzilla emails (most) everyone on the
cc.

The problem with email is self-explanatory. If the bugzilla
notification email isn't being registered in a useful way, probably
more emails won't help either.

2. The very nifty Fedora Blocker Bug Tracking app
https://qa.fedoraproject.org/blockerbugs/

The problem with this is, it's passive. You need to check it. So it's
mainly used by QA folks to get a bird's eye view of the status of
blocker bugs, and freeze exceptions.

3. The illustrious, humorous, verbose, would have been cloned by now
were it affordable and timely enough, adamw, who sends out an email
summary of blocking bugs to devel@.

Problem, more email.

4. Adamw (or less often another human within QA) takes it upon
themselves to inquire via IRC. These are effective. Unknown is if
slips would have resulted if they didn't happen. But it seems at least
plausible that it would increase slips without this form of nagging
(reminding).

The problem is, I think it's inappropriate for any one person to have
to nag other people about their bugs. It's also tedious and manual.
The time and interest for any QA person to do this is low.


The questions then, are:
- Have we reached the pinnacle notification method of blocker bugs to
maintainers? Or is there a better way to do this?

- Would it help to have a nagbot (or enhance zodbot) to ping
maintainers on IRC? Is the nagbot more or less likely to be ignored,
or would it be about the same? Of course there are lower level
questions about whether it's possible, what work it entails, would it
be opt in or opt out, could notifications happen outside IRC, but for
now I think the "in general" high level context is more useful.



-- 
Chris Murphy

[Bruno Wolff III]

On Wed, Jun 29, 2016 at 16:20:32 -0600,
  Chris Murphy <lists(a)colorremedies.com&gt; wrote:
> - Would it help to have a nagbot (or enhance zodbot) to ping
> maintainers on IRC? Is the nagbot more or less likely to be ignored,
> or would it be about the same? Of course there are lower level
> questions about whether it's possible, what work it entails, would it
> be opt in or opt out, could notifications happen outside IRC, but for
> now I think the "in general" high level context is more useful. 
I think it is more likely to annoy people than to help.

[Kevin Fenzi]

On Wed, 29 Jun 2016 16:20:32 -0600
Chris Murphy <lists(a)colorremedies.com&gt; wrote:

...snip...

>  The questions then, are:
>  - Have we reached the pinnacle notification method of blocker bugs to
>  maintainers? Or is there a better way to do this? 
Well, I actually think the human touch here helps. (ie, when adamw does
do a roundup and tries to contact people with an update email), Which
makes it particularly hard to automate without being anoying. 

>  - Would it help to have a nagbot (or enhance zodbot) to ping
>  maintainers on IRC? Is the nagbot more or less likely to be ignored,
>  or would it be about the same? Of course there are lower level
>  questions about whether it's possible, what work it entails, would it
>  be opt in or opt out, could notifications happen outside IRC, but for
>  now I think the "in general" high level context is more useful. 
No, I think it would not help. :) 

First, there's a number of folks who aren't on IRC (shocking I know),
then it gets back to the impersonalness of it... 

I'm not really sure that we have had slips (which as Matt tells us, are
completely expected and fine) due to some maintainer not realizing a
bug was a blocker and not looking at it. In general it's been because
the maintainer has lots of other things going on, or the bug is
difficult to fix and just takes time. 

kevin

[Chris Murphy]

On Wed, Jun 29, 2016 at 5:06 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Wed, 29 Jun 2016 16:20:32 -0600
>  Chris Murphy <lists(a)colorremedies.com&gt; wrote:
>
>  ...snip...
>
> > The questions then, are:
> > - Have we reached the pinnacle notification method of blocker bugs to
> > maintainers? Or is there a better way to do this?
>
>  Well, I actually think the human touch here helps. (ie, when adamw does
>  do a roundup and tries to contact people with an update email), Which
>  makes it particularly hard to automate without being anoying. 

If maintainers are satisfied with the existing official ways of
finding out if they have a blocking bug, then it's a non-issue.

1. Bugzilla email.
2. Adam's roundup email blast to lists.
3. Fedora Blocker Bug Tracking app.
4. Fedora Package Database > Package > Bugs will list blockers apparently.

Then I'd say it's a non-issue. Two of these are active notifications
by email. Two are passive.

The reality is there's a non-trivial number of blocker bugs each
release where none of those four methods registers with the
maintainer. And they only end up becoming aware of the blocker bug
through direct contact.



> > - Would it help to have a nagbot (or enhance zodbot) to ping
> > maintainers on IRC? Is the nagbot more or less likely to be ignored,
> > or would it be about the same? Of course there are lower level
> > questions about whether it's possible, what work it entails, would it
> > be opt in or opt out, could notifications happen outside IRC, but for
> > now I think the "in general" high level context is more useful.
>
>  No, I think it would not help. :)
>
>  First, there's a number of folks who aren't on IRC (shocking I know),
>  then it gets back to the impersonalness of it... 
We know those IRC nags work quickly. And those often happen as a
result of maintainer silence when QA asks in Bugzilla for status
updates.

I also know that no one in QA likes the direct approach, even though
its effective. There's no official mechanism by which direct contact
will happen, it's entirely seat of the pants, and it's inconsistent
when it happens and who does it.


>  I'm not really sure that we have had slips (which as Matt tells
> us, are
>  completely expected and fine) due to some maintainer not realizing a
>  bug was a blocker and not looking at it. In general it's been because
>  the maintainer has lots of other things going on, or the bug is
>  difficult to fix and just takes time. 
I understand slips are expected and fine. But I sense a distinct sad
panda in QA when there's a slip. We probably haven't had a slip due to
a maintainer not realizing a bug was a blocker and not looking at it,
because eventually someone in QA gets annoyed or nervous enough that
they break down and make direct contact. Even I've done this and I'm
about the last personality type who decides to become responsible for
other people's behavior, and it's always been a "oh I didn't know it
was a blocker".

Anyway, in the meantime then, I will encourage QA folks to have a
thicker skin over slips, and not feel like they're obligated to become
personal assistants to remind maintainers about their bugs.


-- 
Chris Murphy