On Wed, Dec 8, 2010 at 1:12 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Wed, 08 Dec 2010 01:05:06 +0000
Bastien Nocera <bnocera(a)redhat.com> wrote:
...snip...
> > The
> > lists may be broken down by when they last did build. With 3
> > exceptions, these 110 bugs are all still in NEW state as well, so
> > they haven't had much maintainer love in quite some time (6-18
> > months).
>
> All the Fedora bugzilla bugs assigned to you, ever:
>
http://bit.ly/dTndTs
> A whole 73.
>
> Fedora Bugzilla bugs in NEW or ASSIGNED assigned to me:
>
http://bit.ly/gBtVRP
> 810 bugs.
>
> When you deal with as many bugs as I (or some other people) do can you
> take executive decisions on blocking packages in newer revisions.
How about asking for help?
Co-maintainers on packages that get lots of bugs?
Have you considered training up some bugzappers to help triage your
components? They could at least work on de-duping abrt reports.
I agree with Bastien on this one. Its very hard and if I spent all my
time dealing with abrt bug reports I'd never do anything else. Besides
I thought abrt was support to support de-dupe.
> I bet most of those packages are still functional, and fail to
build
> due to some minor changes in the build system, or breakage in
> dependency libraries.
The ones he's refering to have not built since f12. It's a wonder if
they work at all. ;)
For some reason I thought we'd had a mass rebuild since f-12 but maybe
that was just python and other sub group stuff. That aside I know of a
number of packages that haven't been rebuilt since F-12 and work just
fine.
> <snip>
> > ModemManager-0.4-4.git20100720.fc14 [u'631152 NEW'] (build/make)
> > dcbw NetworkManager-openvpn-0.8.1-1.fc14 [u'631111 NEW']
> > (build/make) dcbw,choeger,huzaifas,steve
> > NetworkManager-vpnc-0.8.1-1.fc14 [u'631194 NEW'] (build/make) dcbw
>
> And I'm guessing this list didn't get read by humans either.
You are refering to the wrong list.
That was a list of all things that don't currently build right now in
rawhide. The proposed block list was much smaller and contained things
that have not been built since f12.
I don't think blocking things that haven't been rebuilt is such a good
criteria. I also happen to know of at least 1 library that fails to
build on rawhide and F-14 and works perfectly well and if it was
removed I think a large chunk of gnome 3 would fail based on the
dependency tree. I bet that would put the cat amongst the pigeons!
> Feel free to insert here complaints about how the Red Hat
bugzilla is
> slow, bad at reporting, and that abrt reports with missing
> attachments, poor backtraces and no support for tools like GNOME
> Bugzilla's simple-dup-finedr aren't helping us keep the bug count
> down.
It was my understanding that abrt was suppose to block on backtraces
without debuginfo but I still regularly get bugs with little or no
decent info. What's worse is often they are the first report and abrt
de-dupes against that report and still doesn't automatically either
update the backtrace with a complete one from other reports or attach
a new one. So you end up in a situation with a bug report with 30
dupes and have to ask the users to attach a manual complete one. Not
ideal!
Peter