[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

BTS tags: woody, fixed, sid


I already posted this to debian-mentors, but the second part
is a proposal/wishlist for the BTS


----- Forwarded message from Andrea Mennucc <debdev@Tonelli.sns.it> -----

I am confused by how bugs tags are to be used; and
does not clarify things

I have corrected bug 145462 in the latest upload of libprinterconf;
I have added a "closes: #145462" line to the changelog,
and now this bug is closed; but this bug still is alive-and-kicking in
woody, so it has "woody" tag

is it ok? or, should I reopen the bug, and tag it as "fixed"?



actually, IMHO, I think that the whole tag system should be rethinked,
and maybe we should change how bug management is done; here are
some proposal, that we may discuss:

0) we should have many tags called   "fixed-DISTRIB"
 (where DISTRIB is one of the current distributions nicknames)
 to mean that a bug is solved for a distribution, 
 alongside to the tags  "DISTRIB" 

1) when a bug is reported, the BTS should check the "Version: ..."
 line in the report , wrt the versions in the distributions, and
 then it should add a DISTRIB tag for each version that is affected.
 Note that this process cannot always work perfectly, since the BTS has no
 way to determine if other versions are affected, so the mantainer
 should then add all other DISTRIB tags, for any distribution
 that s/he thinks is affected

2) when a package is uploaded to a distribution, and changelog 
 contains a "closes #nnn" command, the upload system should delete the tag
 DISTRIB and add the tag fixed-DISTRIB (and should not close the bug,
  unless.. see 4), where DISTRIB is the distribution where the package 
 is uploaded to;
 note that DISTRIB is usually = to the unstable distribution, that is,
 "sid"; but, this would work also for uploads to
 "woody-proposed-updates", in which case DISTRIB:=woody

3) similarly, when the package moves from unstable to testing, or, when it 
 is accepted in woody, or backported to the stable distribution (maybe
 to fix a security issue, or maybe to build a Debian intermediate
 release such as 3.0v2 ),  then again the appropriate DISTRIB tag would be
 automatically changed to fixed-DISTRIB

4) when a tag is automatically changed to fixed-DISTRIB (as in 2 or 3),
  if there is no more DISTRIB tag , then the bug is automatically

I think that , if we discuss and agree and implement a schema as the
above, then 

+) it would be easier for the Relase Manager to know
  if the packages in the testing distribution are in good shape or not;

+) and, when the RM decides to release an intermediate distribution,
 s/he may check which packages in "stable" are quite buggy and ask for
 a backporting

whereas currently it often happens that, as soon as a package is
uploaded to unstable, the corresponding bugs are closed, and it
is  difficult to know if these bugs are still affecting "testing"
(and more even difficult for "stable")


Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Renato Carotone)

To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

----- End forwarded message -----

Andrea Mennucc
 "E' un mondo difficile. Che vita intensa!" (Renato Carotone)

Attachment: pgpTZxwVIkNTj.pgp
Description: PGP signature

Reply to: