On 27 January 2018 at 21:50, Justin Forbes <jmforbes@xxxxxxxxxxx> wrote:
[..]
> 1) Probably it would be good start posting one time a week summary stats
> about Bugzilla tickets. Any volunteer to create such weekly report?
26 27 rawhide
open: 243 191 288 (722)
Since 2017-12-27
opened: 7 69 15 (91)
closed: 7 36 13 (56)
This is the stats for the past 30 days, which are fairly bad because
1) a *lot* of time has been taken to deal with Spectre/Meltdown and
2) Most kernel folks weren't working for the holidays, and half the
team was travelling last week. I will be happy to start sending out
such reports to the kernel list monthly.
That is OK.
Problem is with very long tail of other still opened tickets.
Again: some of the tickets are in NEW state from 2009.
In last two days I've closed about 10-15 tickets which I found that definitely are 100% outdated.
Every package maintainer can at least spent 1-15 min a month to try have look is anything on the maintained packages list can be closed or not.
Among those tickets I found at least one class which should be not opened against Fedora but exacts project which is producing at the end tar ball used in Fedora package.
This class it is various RFE (Request For Enhance) tickets which none or almost none of the Fedora packagers can implement.
Next: I think that it would be good to have obligatory rule that even if ticket was opened longer 3 to 5 years such ticket should be automatically closed,
Next: as I wrote I found tickets which are opened against packages which are no lo longer part of the Fedora.
Someone who can make query against Bugzilla SQL backend should try to find all those tickets and close them all.
Those packets should be removed from list of Fefora components as well.
One example I've mention already and it is ghdcpd ticket:
Second one is fr example xorg-x11-fonts:
I'm sure that list of such packets/components and tickets is way longer.
It is possible to close those tickets by compare with list of still maintained Fedora packages.
This could be done by Biugzilla admin and cannot be done that way by anyone else.
> 2) Q: do we need new kernel package maintainer or secondary co maintainers?
We currently have 2.5 maintainers, and I believe the .5 is ramping up
to a full time 3. We have asked several times over the years for
people to help with triage, and even have a lovely step by step guide:
https://fedoraproject.org/wiki/KernelBugTriage Very few people seem
interested.
So I was simple unlucky (?) that in +1 years none of my +10 tickets with details about versions and call traces NEVER had even single short msg
"We know about the issue. Closing ad duplicated ticket to <num>"?
Kernel is fast moving package end even within few days tickets with some reported OOPSes is possible to close. Why it does not happen?
Is someone has time to update kernel package why the same person has no time to close few recent tickers wit c&p comment:
"New kernel release is in rawhide repo.
Closing ticket.
Please reopen if issue still is present"
?
Is it really so hard?
After passing +100 still opened tickets per package I can understand that no one wants to even look on new tickets.
This as result does not make any sense opening new tickets. Isn't it?
If current kernel (secondary) maintainers don't want to work on Bugzilla tickets (again) maybe it would be better to find new co-maintainers or add more co-maintainers?
Kernel package is very specific so treating a little differently should be no big deal ..
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
