On Wed, 7 Dec 2005 17:40:33 +0000
Julian Gilbey <[EMAIL PROTECTED]> wrote:
> - putting all the patches in one patch file in one bug report rather
> than 10 different ones in 10 different reports
I'd agree that a 10/10 ratio seems less than efficient. Here are two
fixes; then some hows and whys of the problem, maybe "too much
information" (if so skim or skip), but posted for the record.
Treating a symptom: for one typo repeated over several man
pages in the same package, I could come up with some special code to
combine those before sending.
Workaround: a script might be devised to combine typo reports from
the maintainer side, in any given format a maintainer desired. That is,
you'd run something like 'typo-butler foo', and the script would
collect all the typo bugs for 'foo', their 'diff' data, and present some
interface with a nice overview offering options to weed out dud
typos, apply the good ones, write a boilerplate note to the
changelog, then close the bugs, etc.
(How to design and code these is at present speculative and would
probably require plenty of trial & error.)
Hows and whys:
Combining typo bugs is tricky for packages with many man pages.
Example: 'xscreensaver' now includes 141 man pages; last June I
filed typos in 30 or so of 'em; some pages had more typos than others.
I fear combining all 30 bugs might have made for an overwhelming bug
report.
Many maintainers, (perhaps a majority, soon if not already), aren't
native English speakers; for some evaluating a typo can be difficult.
It's not always obvious in advance who's fluent and who isn't. Small
portions are easier to digest.
Some maintainers, the most talented and energetic even, can be
difficult. Bugs are like attacks on their reputation which may be
deflected by refuting any flaw in them. The more elaborate the report
the better the odds of flaws.
Example: if my error rate was 2% and I submit 100 typos in one bug,
that'd be two mistakes; a proud maintainer in a foul mood might
dispute the two bad ones, (and a few good ones), but ignore the rest
until he was pleased or stonewalls and quits trying. Alas, I'm also
prone to dispute, which increases the odds of trouble. Keeping things
small segregates and minimizes conflict without requiring ideal
maintainers.
A public BTS is a labor saver for users, and all maintainers
are users. It's easier for BTS browsers to understand:
'man plotchangelog' typos: "Alternativly", "approximatly", "displaing",
"immediatly", "initaliazation", "innacturate", etc.
...than this:
devscripts: several man pages have typos
The former subject line lets readers know at a glance the particular
man page and gives a preview of the typos. The latter is vague,
they'd have to read the bug report. Some maintainers prefer
detailed subject lines.
Lesser reason: I haven't coded any proper logging into this tool yet,
at present those detailed BTS subject headers are needed to check where
and what I did, (to say nothing of what others have done), they're a
breadcrumb trail. If other folks used this tool or something like it,
they would also need to know what's been done. Short of inventing and
hosting a special new typo server, (unfeasible with my dial-up ISP),
using the BTS for logging works for now.
Conclusion: the 2005 BTS probably isn't the ideal server tool for typo
fixes. It's better than nothing, and my hope is that given
enough of these bugs, it'll increase the problem's mindshare and
gradually something better can evolve...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
