Proposed package blocking due to FTBFS

[Peter Robinson]

On Wed, Dec 8, 2010 at 1:12 AM, Kevin Fenzi <kevin at scrye.com> wrote:
> On Wed, 08 Dec 2010 01:05:06 +0000
> Bastien Nocera <bnocera at 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