Re: Dealing with GNU/kFreeBSD bugs/notes.

[Roland McGrath <roland at redhat dot com>]

> >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
formalities.

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.


Thanks,
Roland