On Sun, Jan 28, 2018 at 1:09 PM, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote: > 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: > https://bugzilla.redhat.com/show_bug.cgi?id=502717 > Second one is fr example xorg-x11-fonts: > https://bugzilla.redhat.com/show_bug.cgi?id=477486 > > 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? Yes. Mostly because there's no guarantee the newer kernel fixes the issue and it's really not known. So then you get into a cycle of CLOSED->REOPENED->CLOSED->REOPENED *every day* and that's a waste of time and a horrible user experience. > After passing +100 still opened tickets per package I can understand that no > one wants to even look on new tickets. That's not the case for the kernel. > This as result does not make any sense opening new tickets. Isn't it? We need the new tickets. The large number of tickets helps spot patterns that would otherwise not be obvious given the kernel's problem space. If one user reports an issue, it might just be their machine. This happens frequently. If 30 users report the same (or very similar) issue, it's much more likely there is a bug we can hone in on and fix. We need the aggregate data. > 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? There's nothing preventing anyone from doing this today. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
