On Fri, 14 Feb 2003, Robert Elz wrote:

> Frederick Bruckman <fredb@immanent.net> said:
>   | I suggest you use the "install" category for that.
>
>
> Luke Mewburn <lukem@netbsd.org> said:
>   | IMHO, "toolchain" is best place for this type of stuff to go.
>
>
> Well, that's two different suggestions so far ... now you can see why
> I just used "misc".
>
> For what it's worth, if I were looking in the PR database for possible
> reports, I wouldn't be looking in "install", because what I'd expect to
> find there are problems with sysinst, problems with stuff missing from
> the sets, or missing from the embedded root filesystem in the install
> kernel - or other things going wrong while installing NetBSD (core dumps
> from pax even perhaps...).   The bugs of concern here aren't that (nothing
> even slightly similar really).
>
> Toolchain was the closest I would have picked, but there I'd really expect
> to see bug reports of the compiler system (in general) and anything that
> goes in ${TOOLDIR} while running build.sh and how all of that works
> together.

OK then, "toolchain" it is.

> That's close, but not quite right, and I suspect would bother the compiler
> (etc) people a lot with reports about problems that have nothing at all
> to do with them.  Nothing that ever resides inside ${TOOLDIR} is affected.

True, but Luke has taken charge of the release building stuff these
days, so if he's watching for bug reports in "toolchain", then that
would be the place to put them.

> If any of the people who normally deal with install, or toolchain, PRs
> wants to look at what is currently misc/20279 or misc/20330 and tell me
> that you'd be happy for more of that kind of PR in your category (and ideally
> demonstrate that, by actually fixing the bugs reported - they're trivial,
> won't take any effort...) then I'll be happy to continue sending new such
> reports to that category.
>
> The ones in question could even conceivably have been directed at the xsrc
> category, because they both relate to the X sets - but they don't have
> anything at all do do with anything under the xsrc source tree, so that
> also didn't look right to me.   Other (almost identical) problems would
> be clearly irrelevant to xsrc.

More categories won't necessarily make things easier. It's already
fairly common for the same problem to be reported multiple times, in
different categories.

Although there are category leaders, their involvement varies. It
wouldn't surprise me at all to find that there were no
"bin-bug-people" at all, same for "misc" and "lib". The way it really
works: any one can subscribe to get all the bug reports, and probably
most developers do. When a developer sees something that interests
him, or that he's responsible for, he fixes it right away. If it
doesn't get fixed quickly, there's no escalation procedure; it just
stays in the database until someone happens to pick it up, maybe for
a long time.

Frederick