From a bug triage perspective is there anything I could do on the bugs
above? Do the ones that include code changes need testcases? (It seems
they could only have meaningful testcases for GNU/kFreeBSD.)
Is there a general principle which determines what GNU/kFreeBSD items will
or will not go into libc?
I could put a note in the bug saying "Looked at for bug triage. No action
needed." or we could have a bugzilla flag to that effect. Or perhaps it is
sufficient to put "examined: +" and "testcase: n/a" where "n/a" would mean
Of course the questions apply to other non-primary ports and possibly
other cases I can't think of.
Dwayne Grant McConnell wrote:
> Of course the questions apply to other non-primary ports and possibly
> other cases I can't think of.
Like architectures. There are categories missing in bugzilla. One way
to solve this is to create email aliases (like for the ports) and assign
bugs to those. When triaging the bugs assigned to those names can be
For now, change the component for all non-Linux/non-Hurd bugs and all
bugs for archs not in the main tree to 'ports'. The interested parties
can fish th ebugs out of that bucket. This leaves the problem of mips.
If nobody steps up as the assignee I am inclined to close all of them
as WONTFIX before nobody cares.
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
> >From a bug triage perspective is there anything I could do on the bugs
> above? Do the ones that include code changes need testcases? (It seems
> they could only have meaningful testcases for GNU/kFreeBSD.)
Things that are not bug fixes or interface enhancements per se do not
need test cases. When a test case could help, it should be there.
Whether or not there should be a test case, the other useful triage
criteria to apply are whether the patch applies cleanly, and whether it
appears obvious on the face of it that the change is harmless, is
stupid, is hairy, etc. Without being too confident about your own
analysis of the code changes, you can certainly check that new source
lines are formatted to the proper conventions, that proper ChangeLog
entries are supplied, and that copyright assignments are in order. (If
you do not already know how to check on copyright status yourself with
the FSF, we can arrange for you to do so.) Of course, it is not worth
your efforts to check these things and ask the submitter to clean them
up, for a change that's undesireable and going to be rejected anyway.
But these are things you can do while waiting for authoritative
developers to look at the issue and make decisions. When you can't
tell, use your judgement based on your guess of the likelihood of
acceptance, and the amount of effort required to check on all the
I had intended the "ports" category in bugzilla for bug reports for
non-core configurations, which need to be debugged and fixed by the
volunteer maintainers of those configurations, many of which are in the
ports repository. Core maintainers don't think about these bugs at all,
until there is a fix submitted or approved by a volunteer maintainer.
These reports you mention are a different class of item; they are
requests for core glibc changes in aid of non-core configurations. They
need to be dealt with by core maintainers, when a core maintainer wants
to consider "not core bugs" items usually given lower priority than bug
reports about problems experienced on core configurations. (In
practice, I might be the only core maintainer who wants to spend any
time on those these days.)
The purpose of the bugzilla categories and flags and such is to make it
easier to manage the reports into prioritized queues of items core
maintainers' time is well-spent working on. We can add and change the
bugzilla categories, flags, or keywords, any time we like. I will
gladly make any changes that people think help organize things. Another
thing that can be used similarly is tracker bugs. e.g., perhaps we
should have a tracker for "enabling core changes ports are waiting for",
whose dependencies are all the bugs of that kind.
> This leaves the problem of mips.
> If nobody steps up as the assignee I am inclined to close all of them
> as WONTFIX before nobody cares.
These can be reassigned to the ports component. mips for the trunk is
moving to ports soon. For this and other configurations that are in ports
now but are in core 2.3, we may want to think more about the plan. (That
would go along with whatever the general plan is to coherently track fixes
that need to go onto a stable branch.)