> Since no one else seems to be in the mood to say anything either...
>
> What sort of things do we want to start aiming for? Certainly we want to
> keep killing release-critical bugs, but do we also want to try minimising
> normal/wishlist bugs in, say, base or important packages?
i think that's probably one of the most important things to do, as
well as bugs with installation... imho a headache free install is
vastly more important than headache free running, especially since
bugs in running programs are easier to document.
> Should we start going through the lintian bugs, and start harassing (err,
> sending patches to) the maintainers of some of the packages with easily
> fixed lintian bugs?
ooc, what's lintian? sorry... i'm new.
> Should we work on fixing up the perennial problem of missing manpages,
> and removing all the links to undocumented(7)?
not one of the highest priority things, since i'd imagine most of
those things have an acceptable /usr/doc/ entry. perhaps that's
incorrect though.
> I still think it'd be good to have a -qa homepage somewhere to keep track
> of where we're up to on things like this, too.
<waste type="bandwidth">me too</waste>
> > I personally know C, C++, and perl, and have poked at numerous
> > others. bash, python, scheme, java.... I think I'm capable of hunting down
> > upstream bugs.
>
> Ditto, FWIW.
i'm fair at c, c++, perl, {ba,}sh, and scheme, have done a bit of
java, and categorically refuse to learn python on the basis that it
conflicts with my fundamental sense of aesthetics (sorry, i just can't
stand anything that has indentation-based flow control). i could
probably hunt down upstream bugs decently efficiently.
--phouchg
pgp key available from pgp.ai.mit.edu or finger [EMAIL PROTECTED]
