GLIBC bug list on sourceware.org

GLIBC bug list on sourceware.org

[Adhemerval Zanella]

Hi all,

As Joseph has pointed out earlier in IRC, sourceware.og just surpassed 
1000 registered bugs [1].  And this list only increases over time.

I cracked down by category and current list (when this mail was crafted,
Oct-20) is:

Component		# Bugs
libc			220
dynamic-link		96
network			94
localedata		93
nptl			79
manual			55
locale			52
build			46
stdio			45
math			43
malloc			33
string			26
regex			24
time			24
nscd			18
librt			12
glob			11
nss			11
admin			7
hurd			4
nis			4
soft-fp			2
buildbot		1

Also, as Joseph has commented on IRC and I agree with him, the expectation is 
that fewer than half the bugs are actually genuine issues that are hard to fix;
maybe fewer than 200. There are lots that should be easy to fix (or easy for
someone familiar with the relevant architecture, in some cases), and probably
a fair number that are really feature requests that need consensus to be
reached.

So I think a initial triage to check for actual bugs with some ping to get
consensus can help on get this under control.  My idea is to use this thread
to reference bugs that might not be real issues to ask for a second look and
thus close them.

Another following idea is to also prioritize the bugs issues once the triage 
is done.

Any thoughts, ideas, advices?

[1] https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&limit=0&list_id=32453&order=component%2Cchangeddate%2Cproduct%20DESC%2Cbug_id%20DESC&product=glibc&query_format=advanced

Re: GLIBC bug list on sourceware.org

[Chris Leonard]

On Thu, Oct 20, 2016 at 3:35 PM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> Hi all,
>
> As Joseph has pointed out earlier in IRC, sourceware.og just surpassed
> 1000 registered bugs [1].  And this list only increases over time.
>
> I cracked down by category and current list (when this mail was crafted,
> Oct-20) is:
>
> Component               # Bugs

> localedata              93


>
> Also, as Joseph has commented on IRC and I agree with him, the expectation is
> that fewer than half the bugs are actually genuine issues that are hard to fix;
> maybe fewer than 200. There are lots that should be easy to fix (or easy for
> someone familiar with the relevant architecture, in some cases), and probably
> a fair number that are really feature requests that need consensus to be
> reached.
>
> So I think a initial triage to check for actual bugs with some ping to get
> consensus can help on get this under control.  My idea is to use this thread
> to reference bugs that might not be real issues to ask for a second look and
> thus close them.
>
> Another following idea is to also prioritize the bugs issues once the triage
> is done.
>
> Any thoughts, ideas, advices?



I'd love to help work on the localedata tickets.  Some of them are
actually mine (new locales).  I've tried posting some patches to the
list, but have encountered challenges as posts are apparently tripping
a spam filter.

cjl

Re: GLIBC bug list on sourceware.org

[Siddhesh Poyarekar]

On Friday 21 October 2016 01:05 AM, Adhemerval Zanella wrote:
> Another following idea is to also prioritize the bugs issues once the triage 
> is done.
> 
> Any thoughts, ideas, advices?

Carlos and I had talked about this in the past and we had agreed on
using the release freeze time to try and bring the number of pending
bugs down.  We could try and make that idea into a more formal process,
by making the slushy freeze time an official thing and encourage devs to
work on reducing the bug backlog in that time.

The trouble however is that very few contributors do glibc work full
time and freezes are usually the time that they move on to do other
things, unless they have pending patches or features that they care about.

Siddhesh

Re: GLIBC bug list on sourceware.org

[Carlos O'Donell]

On 10/24/2016 10:27 PM, Siddhesh Poyarekar wrote:
> On Friday 21 October 2016 01:05 AM, Adhemerval Zanella wrote:
>> Another following idea is to also prioritize the bugs issues once the triage 
>> is done.
>>
>> Any thoughts, ideas, advices?
> 
> Carlos and I had talked about this in the past and we had agreed on
> using the release freeze time to try and bring the number of pending
> bugs down.  We could try and make that idea into a more formal process,
> by making the slushy freeze time an official thing and encourage devs to
> work on reducing the bug backlog in that time.
> 
> The trouble however is that very few contributors do glibc work full
> time and freezes are usually the time that they move on to do other
> things, unless they have pending patches or features that they care about.

We consciously choose a time-boxed release, and the consequence of that is
that we should be doing bug fixes in a continuous fashion.

I think we need some kind of weekly or monthly bug review which tries to
squash the bugs that have popped up.

https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&f1=creation_ts&list_id=32518&o1=greaterthan&product=glibc&query_format=advanced&v1=2016-10-17

Last week we had 4 new bugs.

20729 	glibc-2.24 fails to build for i486 with -Os
20728 	powerpc: Missing TOC stub in clone
20720 	ntfw with FTW_CHDIR and FTW_DEPTH can't back out of a tree properly giving ENOENT
20708 	Extra test failures with LD_BNID_NOW=1
20707 	gl_pathv entries not set to NULL with GLOB_DOOFFS 

I'd focus on practicing a weekly triage of whatever was opened that week.

-- 
Cheers,
Carlos.

Re: GLIBC bug list on sourceware.org

[Carlos O'Donell]

On 10/20/2016 03:35 PM, Adhemerval Zanella wrote:
> Hi all,
> 
> As Joseph has pointed out earlier in IRC, sourceware.og just surpassed 
> 1000 registered bugs [1].  And this list only increases over time.
...
> Any thoughts, ideas, advices?

Do the work? :-)

I created a 7day review query for bugzilla.

Florian and I just fixed the -Os bug that came in.

We just need to target the incoming bugs and drive them to conclusion.

It's the only way we'll win.

Enough practice at that and we'll start making progress.

Last week was a 0 bug delta, we fixed all the reported bugs.

This week I'm tackling the Venezuela locale bug and I'll see if that
can be moved to fixed too.

-- 
Cheers,
Carlos.

Re: GLIBC bug list on sourceware.org

[Andrew Pinski]

On Sat, Oct 29, 2016 at 9:01 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/20/2016 03:35 PM, Adhemerval Zanella wrote:
>> Hi all,
>>
>> As Joseph has pointed out earlier in IRC, sourceware.og just surpassed
>> 1000 registered bugs [1].  And this list only increases over time.
> ...
>> Any thoughts, ideas, advices?
>
> Do the work? :-)
>
> I created a 7day review query for bugzilla.
>
> Florian and I just fixed the -Os bug that came in.
>
> We just need to target the incoming bugs and drive them to conclusion.

In GCC, that is what I try to do; though the number of bugs reported
are high and many include missed optimization which are not easy to
fix right away.  What I also have been trying to do is clean up the
much older ones which are more than 3-4 years old now.  This week GCC
is -2 but the week before is +17 and week before that was +3; overall
in the last year GCC is +536 (more than one a day).  For GCC, the C++
front-end is the area which has gotten out of control; not enough
developers :(.  Anyways this is getting offtopic now but it shows how
you can track things a little bit and how things can speed out of
control if an area is not covered by enough developers.

Thanks,
Andrew

>
> It's the only way we'll win.
>
> Enough practice at that and we'll start making progress.
>
> Last week was a 0 bug delta, we fixed all the reported bugs.
>
> This week I'm tackling the Venezuela locale bug and I'll see if that
> can be moved to fixed too.
>
> --
> Cheers,
> Carlos.

Re: GLIBC bug list on sourceware.org

[Carlos O'Donell]

On 10/30/2016 12:41 AM, Andrew Pinski wrote:
> On Sat, Oct 29, 2016 at 9:01 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> We just need to target the incoming bugs and drive them to conclusion.
> 
> In GCC, that is what I try to do; though the number of bugs reported
> are high and many include missed optimization which are not easy to
> fix right away.  What I also have been trying to do is clean up the
> much older ones which are more than 3-4 years old now.  This week GCC
> is -2 but the week before is +17 and week before that was +3; overall
> in the last year GCC is +536 (more than one a day).  For GCC, the C++
> front-end is the area which has gotten out of control; not enough
> developers :(.  Anyways this is getting offtopic now but it shows how
> you can track things a little bit and how things can speed out of
> control if an area is not covered by enough developers.

Then we need to convince our employers that more C++ front-end developers
are needed to fix the problems. But we won't know this if we don't track
the bugs and try to understand where our users are having problems.

On a positive note the Red Hat investments in malloc (DJ) and the stub
resolver (Florian) are directly driven by analyzing bugs and user
feedback.

Cheers,
Carlos.