GLIBC bug list on sourceware.org

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GLIBC bug list on sourceware.org

Adhemerval Zanella-2
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
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Chris Leonard
On Thu, Oct 20, 2016 at 3:35 PM, Adhemerval Zanella
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Siddhesh Poyarekar-8
In reply to this post by Adhemerval Zanella-2
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
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Carlos O'Donell-6
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.
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Carlos O'Donell-6
In reply to this post by Adhemerval Zanella-2
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.
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Andrew Pinski-3
On Sat, Oct 29, 2016 at 9:01 PM, Carlos O'Donell <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: GLIBC bug list on sourceware.org

Carlos O'Donell-6
On 10/30/2016 12:41 AM, Andrew Pinski wrote:

> On Sat, Oct 29, 2016 at 9:01 PM, Carlos O'Donell <[hidden email]> 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.