Re: coordination? (was: APT 0.6 development: who to synchronize with?)
> In the past I've been sending merge requests mostly via BTS or via
> IRC. I'll use this list in the future more often.
This list receives all BTS mail. So, when working on bugs, the best is
certainly to write to xxxxx@b.d.o (not -quiet, of course). This is how
we proceed for the shadow package development.
About bug triage, let me paste the small text I have written for
shadow bug triage. This is a kind of common ground for best use of bug
tags and pseudo-tags.
pseudo-tagging has proven to be quite useful (Scott uses it for dpkg)
for srting things for which no BTS tag is appropriate.
For the work about APT, maybe something could be taken from the
following.
Please note that I have chosen a quite aggressive work method to deal
with shadow bugs, especially for bugs for which "moreinfo" is
mentioned and we receive no input. In the same way, I have decided,
for shadow, to *close* all bugs marked as "wontfix", except in very
special occasions (mostly things which are very likely to be reported
again and again).
The use of BTS tags and pseudo-tags in shadow package bug triage
----------------------------------------------------------------
BTS tags.
--------
Please also read /usr/share/doc/debian/bug-maint-info.txt for the
"normal" meanings
patch
Means someone submitted a patch. If the patch is commited,
to the CVS, add "pending"
wontfix
Only for bugs we really want to keep opened and don't
want to see reported again and again
moreinfo
For old bugs we've asked confirmation of. CLOSE these bugs
when nothing comes
unreproducible
Normal meaning. Should most often be coupled with moreinfo
help
We need some external help
pending
ONLY when the fix has been commited to the CVS
fixed
Please don't use
security
Normal meaning
upstream
ALL bugs in shadow's code (ie not pertaining to Debian packaging
or Debian specific scripts) should be marked that way
confirmed
Normal meaning. Please use it as much as possible
when bugs are OK for you but the fix is yet to come or you
don't have time or skills to fix it yourself
fixed-upstream
VERY IMPORTANT as we work with upstream. Tag that way ALL bugs
for which the fix has been commited by Tomasz in his CVS
fixed-in-experimental
We'll see if we use experimental..:-)
d-i
All bugs that affect the installer. For shadow, this should mostly
be things related to passwd.config script
ipv6
Irrelevant for us
lfs
Normal meaning
l10n
Normal meaning. ALso include documentation translation and i18n
issues
potato
Irrelevant..:)
woody
Hopefully, we won't use it often
sarge
Will become important if we decide to keep opened all bugs fixed
in unstable/testing when sarge will have been released
sarge-ignore
Normal meaning
sid
Normal meaning
experimental
Normal meaning
Pseudo-tags
-----------
We need more granular triaging. So, we will also use pseudo-tags in
bug titles. The usual bracket method is to be used.
[POST-SARGE] : bug will be fixed/dealt with after sarge release
as, now, all bugs are that flavour, this could be dropped
but this is indeed a convenient way to easily see what
has been already investigated
[<first name>] : bug is attributed to one of us
(Christian, Nicolas, Alexander...)
Use capitals
[TO CLOSE yyyymmdd] : without further notice, this bug may be closed
one week after the last request for comment
[DEBIAN DECISION] : dealing with this bug is a design choice which must
be discussed with other DD's or even the Technical
Comitee
[EXPERT] : this bug, though not needing a design decision
needs an external expert advice (somewhat redundant)
with the "help" tag. Use with care, please...
Reply to: