Re: Bugzilla: You can't ask Lennart Poettering because that account is disabled.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jul 02, 2022 at 05:31:13PM -0500, Maxwell G via devel wrote:
> On Saturday, July 2, 2022 3:11:44 PM CDT Kevin Fenzi wrote:
> > On Sat, Jul 02, 2022 at 11:54:17AM -0500, Maxwell G via devel wrote:
> > > On Saturday, July 2, 2022 10:01:18 AM CDT Michael Catanzaro wrote:
> > > > This is an extremely common problem in Fedora: the de facto maintainer
> > > > is not the main admin, and so the bugs are assigned to the wrong
> > > > person. Ideally we would automatically orphan a package if the main
> > > > admin does not have any commits to the package for a certain period of
> > > > time, e.g. three years.
> > > 
> > > It would help if other people besides the main admin could change the
> > > Bugzilla assignee. After all, if the main admin is non-responsive, it's
> > > going to be difficult to get them to do it.
> > 
> > I'm not sure the main admin matters as much as this thread indicates?
> > All the other maintainers of the package are CC'ed, in this case
> > belegdol.
> 
> Maybe the main admin isn't so important, but the Bugzilla assignee is. 
> Packages should be assigned to the person who is actually maintaining it. This 

Well, what if it's 2 people and they trade off? Or 3 ? or 4?
Or some people handle bugs in one area and others in another... having
only one 'assignee' is kind of limiting. ;( 

> makes it so bugs are more likely to be addressed. Then, the bugs will also 

I'm not sure that it makes bugs more likely to be addressed. 
The only difference between assignee and someone on cc is what field
bugzilla shows. They both get email, no?

> show up in the "Open bugs assigned to me" link on the Bugzilla homepage[1] for 
> the actual maintainer. This is more important for EPEL than Fedora proper. For 
> packagers who don't care about EPEL, EPEL bugs should be assigned to the co-
> maintainer (or the epel-packagers-sig) who actually maintains the EPEL 
> branches; the latter should be held responsible to fix bugs and be the one who 
> is NEEDINFO'd (when/if that happens), not the Fedora maintainer. It seems like 
> there is at least some agreement in this area[2].

Ah, I never use that anymore. 
I tend to use command line 'bugzilla query' or 
https://packager-dashboard.fedoraproject.org/
along with emails.

But perhaps you're right as I have a lot of bugs and could probibly do
better prioritizing.

I personally don't like NEEDINFO. We don't have any common perception of
when it should be used and it can be used by anyone. :( I only use
needinfo on things that are time sensitive and some specific information
is required from the needinfo target. Like "can you fix this in time to
do a new compose before go/no-go". Others use it for an implied 'do you
plan to fix this bug', others 'it's been a while and you didn't get to
this bug so are you going to?'. Some people even set it right away when
the bug was filed, not leaving any time for 'normal' processing.

When/if we move off bugzilla we should take all these considerations
into what we end up choosing and ways to make these workflows better.

kevin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux