This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposed changes to Bugzilla components
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 24 Aug 2015 17:35:35 +0200
- Subject: Re: Proposed changes to Bugzilla components
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1508240921140 dot 30525 at digraph dot polyomino dot org dot uk> <55DAFFCD dot 1070004 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1508241129360 dot 13809 at digraph dot polyomino dot org dot uk>
On 08/24/2015 01:34 PM, Joseph Myers wrote:
> On Mon, 24 Aug 2015, Florian Weimer wrote:
>
>> On 08/24/2015 11:41 AM, Joseph Myers wrote:
>>
>> These two a very difficult to tell apart:
>>
>>> * network is "Any network-related functionality e.g. getaddrinfo etc.".
>>> Suggest changing "network-related" to "network-related or socket-related"
>>> (sockets may not strictly be networking, but this seems the best place for
>>> issues about generic socket functions).
>>
>>> * nss "Name Service Switch.".
>>
>> Mainly because network explicitly mentions getaddrinfo. It's also not
>> clear where to put resolv issues (but it could get its own component).
>
> I'm thinking of nss as being non-network nss issues, while network
> includes resolv issues. 18356 (currently network) would be nss, 18724
> (currently network) would be libc (putpwent isn't NSS), libc issues that
> would be nss include at least 12459, 15385, 17250.
I'm not sure if the distinction is always so clear-cut, but I don't have
strong feelings about it.
>> The miscellaneous component is also somewhat difficult to find in my
>> experience.
>
> You mean libc?
Indeed.
> I think the problem with it is there are too many issues
> there (which to some extent can only be addressed by people working
> through them and fixing them - or, where issues request new features,
> seeking consensus on libc-alpha about whether those features are desirable
> at all; that also applies to issues in various other components).
I think it should be called “misc” or “general”. Or there should be an
“unclassifed” component selected by default.
--
Florian Weimer / Red Hat Product Security