Re: Version tracking in the BTS

[Russ Allbery]

Adeodato Simó <[EMAIL PROTECTED]> writes:
> * Russ Allbery [Tue, 30 Aug 2005 10:47:12 -0700]:

>> Unfortunately, for a package with a moderate number of bugs (10-30), it
>> adds a lot of clutter without a lot of clarity.  Because of that, it
>> would be great if there were some option down in the settings section
>> that would let one turn off this section splitting again.

>   You mean &oldview=yes?

>   (http://lists.debian.org/debian-devel/2005/08/msg01769.html)

Yup, that's it.  Thanks!

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: Version tracking in the BTS

[Adeodato Simó]

* Russ Allbery [Tue, 30 Aug 2005 10:47:12 -0700]:

> Unfortunately, for a package with a moderate number of bugs (10-30), it
> adds a lot of clutter without a lot of clarity.  Because of that, it would
> be great if there were some option down in the settings section that would
> let one turn off this section splitting again.

  You mean &oldview=yes?

  (http://lists.debian.org/debian-devel/2005/08/msg01769.html)

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
There may be no I in TEAM, but a M and an E.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Anthony Towns]

On Wed, Aug 31, 2005 at 10:28:07AM +0100, Scott James Remnant wrote:
> This isn't great for the "maintainer view" of the bugs.  As maintainer,
> I can't do anything about bugs in stable, so I don't want to see them on
> the bug list.

They'd appear as a resolved bug in the default view, so shouldn't get
in your way much. If it becomes a problem we can probably come up with
some way of "disappearing" unarchived-but-still-quite-old resolved bugs.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Steve Langasek]

On Wed, Aug 31, 2005 at 10:28:07AM +0100, Scott James Remnant wrote:
> On Mon, 2005-08-29 at 23:42 -0700, Steve Langasek wrote:

> > I don't know if it's feasible, but my ideal vision for how the new
> > version tracking would handle bugs in stable would be that if the
> > version in stable is affected, the bug is left open if it's tagged
> > sarge or if it's of RC severity; otherwise the bug is archived normally.
> > I don't even see a reason to special-case "security", most such bugs are
> > going to be of RC severity and the others can be tagged with the
> > per-suite tag just as we've been doing.

> This isn't great for the "maintainer view" of the bugs.  As maintainer,
> I can't do anything about bugs in stable, so I don't want to see them on
> the bug list.

Then use the (default) unstable view of the BTS, where they will be
listed as closed bugs only?  The question is whether the bugs should be
*archived*, not whether they should be displayed by default as open.

Though anyway, my whole point in suggesting that these bugs not be
archived is that they're the ones that Joey's policy does appear to
allow maintainers to do something about.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Scott James Remnant]

On Mon, 2005-08-29 at 23:42 -0700, Steve Langasek wrote:

> I don't know if it's feasible, but my ideal vision for how the new
> version tracking would handle bugs in stable would be that if the
> version in stable is affected, the bug is left open if it's tagged
> sarge or if it's of RC severity; otherwise the bug is archived normally.
> I don't even see a reason to special-case "security", most such bugs are
> going to be of RC severity and the others can be tagged with the
> per-suite tag just as we've been doing.
> 
This isn't great for the "maintainer view" of the bugs.  As maintainer,
I can't do anything about bugs in stable, so I don't want to see them on
the bug list.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


signature.asc
Description: This is a digitally signed message part

Re: Version tracking in the BTS

[Anthony Towns]

On Tue, Aug 30, 2005 at 10:45:47AM -0700, Russ Allbery wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> > Having those bugs classified as "patched" IMO gives the wrong impression
> > to casual readers (read non-developers) as it indicates that the problem
> > has already been fixed.
> > I personally read "patched" as synonymous to "patch has been applied",
> > which is just not true.
> Something like "patch available" would sound a lot better to me [...]

Changed.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005.08.30.0729 +0200]:
>> How about adding documentation to the bugs.debian.org webpage?
>
> How about a patch? Writing the documentation yourself has the added
> benefit that you won't need it in the future anymore.

1) That's not true: I'll forget.  Writing it doesn't mean I won't
   forget it.

2) I don't know all the changes that have been made. 

3) There is a bad habit of making announcements on the announcement
   mailing list by people who skip the *more* important job of keeping
   the actual documentation up to day.

4) I'm busy trying to do my own job, rather than managing others' too.

The bugs.debian.org changes are superb and wonderful.  But you can't
chide someone for not knowing about them when the documentation isn't
up to day.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Russ Allbery]

Helmut Wollmersdorfer <[EMAIL PROTECTED]> writes:
> Frans Pop wrote:

>> In an perfect world a maintainer would review each patch as it is
>> submitted and remove the tag if the patch is not good.

> In common sense a patch is a proposed solution for a bug, independent
> from the author (bug submitter, maintainer, upstream or somebody else).

> Each sort of proposed solution needs an approval (e.g. regression test),
> if it removes the bug. If not, the bug cannot be closed as
> 'solved'. Thus I do not understand, why to remove the 'patch' tag.

Because if a bug is tagged with patch, other people looking over the bug
logs and wanting to be helpful (like me) will skip over the bug on the
assumption that it's already being dealt with.  So if the maintainer isn't
happy with the solution, they should remove the patch tag so that others
know that no solution has yet been found.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Helmut Wollmersdorfer]

Frans Pop wrote:

On Monday 29 August 2005 21:59, Anthony Towns wrote:



On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:



   A patch or some other easy procedure for fixing the bug is included
   in the bug logs. If there's a patch, but it doesn't resolve the bug
   adequately or causes some other problems, this tag should not be
   used.

[...]
In an perfect world a maintainer would review each patch as it is 
submitted and remove the tag if the patch is not good. 


In common sense a patch is a proposed solution for a bug, independent 
from the author (bug submitter, maintainer, upstream or somebody else).


Each sort of proposed solution needs an approval (e.g. regression test), 
if it removes the bug. If not, the bug cannot be closed as 'solved'. 
Thus I do not understand, why to remove the 'patch' tag.


Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[martin f krafft]

also sprach Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> [2005.08.30.2111 
+0200]:
> Shorter: "with patch" (which could be moved to "with good patch" if the tag
> +patch and +confirmed where used?

Confirmed is a tag used when the maintainer can reproduce the bug,
not when the patch is confirmed.

> "patched" looks more like it should be used when +patch and
> +pending have been used)

Pending makes no suggestion whether the patch was used, or another
solution found.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"the 'volatile' keyword
 is implemented syntactically
 but not semantically"
  -- documentation of m$ visual c, around 1992


signature.asc
Description: Digital signature (GPG/PGP)

Re: Version tracking in the BTS

[Javier Fernández-Sanguino Peña]

On Tue, Aug 30, 2005 at 10:45:47AM -0700, Russ Allbery wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> 
> > Having those bugs classified as "patched" IMO gives the wrong impression
> > to casual readers (read non-developers) as it indicates that the problem
> > has already been fixed.
> 
> > I personally read "patched" as synonymous to "patch has been applied",
> > which is just not true.
> 
> Something like "patch available" would sound a lot better to me than
> "patched," although it's longer.  That's then still true even if the patch
> is bad and just hasn't been triaged yet.

Shorter: "with patch" (which could be moved to "with good patch" if the tag
+patch and +confirmed where used? "patched" looks more like it should be used
when +patch and +pending have been used)

Regards

Javier


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Russ Allbery]

Hamish Moffatt <[EMAIL PROTECTED]> writes:

> IMHO it's useful to split out confirmed. For packages with large bug
> lists, splitting confirmed from still-be-to-be-analysed reports is a big
> improvement.

I think the new classification is very useful for packages with lots of
bugs.  It makes the bug list much more manageable.  Thank you!

Unfortunately, for a package with a moderate number of bugs (10-30), it
adds a lot of clutter without a lot of clarity.  Because of that, it would
be great if there were some option down in the settings section that would
let one turn off this section splitting again.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Russ Allbery]

Frans Pop <[EMAIL PROTECTED]> writes:

> Having those bugs classified as "patched" IMO gives the wrong impression
> to casual readers (read non-developers) as it indicates that the problem
> has already been fixed.

> I personally read "patched" as synonymous to "patch has been applied",
> which is just not true.

Something like "patch available" would sound a lot better to me than
"patched," although it's longer.  That's then still true even if the patch
is bad and just hasn't been triaged yet.

-- 
Russ Allbery ([EMAIL PROTECTED]) 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Hamish Moffatt]

On Tue, Aug 30, 2005 at 05:59:17AM +1000, Anthony Towns wrote:
> The idea is that a maintainer can divide bugs by the actions needed:
> 
> * patch: apply the patch, build, test, upload
> * moreinfo: no action -- waiting for more info
> * wontfix: no action -- won't fix anyway
> * unclassified: reproduce, analyse, come up with solutions
> * confirmed: analyse, come up with solutions
> 
> Bugs tagged "help", "unreproducible", and "upstream" aren't separated
> out from unclassified at the moment; maybe "confirmed" shouldn't be
> split from unclassified.

IMHO it's useful to split out confirmed. For packages with large bug
lists, splitting confirmed from still-be-to-be-analysed reports is
a big improvement.

thanks,
Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 21:59, Anthony Towns wrote:
> On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> > Also I don't think that "Patched" as a description for tag 'patch' is
> > correct. The bug has not been patched, there just is a _proposed_
> > patch available. There is no certainty that the patch is either
> > correct or will be accepted by the maintainer.
>
> If it's known to be incorrect or the maintainer's not going to accept
> it, the patch tag isn't appropriate:
>
> A patch or some other easy procedure for fixing the bug is included
> in the bug logs. If there's a patch, but it doesn't resolve the bug
> adequately or causes some other problems, this tag should not be
> used.

Thanks for the clarification. The reality however is that a lot of patches 
(of varying quality) are submitted to the BTS by others than the 
maintainer and may linger for quite a while before they are properly 
reviewed by the maintainer.
Having those bugs classified as "patched" IMO gives the wrong impression 
to casual readers (read non-developers) as it indicates that the problem 
has already been fixed.
I personally read "patched" as synonymous to "patch has been applied", 
which is just not true.

In an perfect world a maintainer would review each patch as it is 
submitted and remove the tag if the patch is not good. Reality is 
different, although I hope the recent enhancements to the BTS may help to 
get it used better.


pgpytY0uVH2HB.pgp
Description: PGP signature

Re: Version tracking in the BTS

[Steve Langasek]

On Tue, Aug 30, 2005 at 05:43:52AM +1000, Anthony Towns wrote:

> I'd kind-of hope it wouldn't be an issue in practice -- security bugs
> that're fixed in unstable ought to have the fix for stable uplaoded
> within 28 days anyway, shouldn't they?

Well, there's the mozilla packages, for one example where this hasn't
been the case in practice.  I would rather not have security bugs in
stable be forgotten about because they passed some threshold where the
BTS auto-vanished them.

I don't know if it's feasible, but my ideal vision for how the new
version tracking would handle bugs in stable would be that if the
version in stable is affected, the bug is left open if it's tagged
sarge or if it's of RC severity; otherwise the bug is archived normally.
I don't even see a reason to special-case "security", most such bugs are
going to be of RC severity and the others can be tagged with the
per-suite tag just as we've been doing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[martin f krafft]

also sprach Thomas Bushnell BSG <[EMAIL PROTECTED]> [2005.08.30.0729 +0200]:
> How about adding documentation to the bugs.debian.org webpage?

How about a patch? Writing the documentation yourself has the added
benefit that you won't need it in the future anymore.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: Version tracking in the BTS

[Thomas Bushnell BSG]

martin f krafft <[EMAIL PROTECTED]> writes:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
>> Which tags are used for classification? sarge et al.?  Would it make
>> sense to tag a bug "sarge" if it is reported against the version in
>> sarge (even though this is technically incorrect)?
>
> Please read the announcement about the new meaning of these tags:
>
>   http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

How about adding documentation to the bugs.debian.org webpage?  I
don't normally read through debian-devel-announce when looking for
documentation. 

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Anthony Towns]

On Mon, Aug 29, 2005 at 08:16:36PM +0200, Florian Weimer wrote:
> Would it be possible to include such information in the bug-specific
> page as well, or at least a link to obtain it?

Well, anything's possible. The versioning checks are somewhat slow and
cumbersome at the moment; so they're only done when /specifically/
requested, which is only possible for pkgreport listings atm. I guess
what you mean is you'd like something like:

* Bug applies to testing only!

somewhere obvious in the bugreport page.

> | Outstanding bugs -- Grave; Unclassified (1 bug)
> | * #324167: OpenVPN 2.0-1 vulnerabilities
> |   Package: openvpn (openvpn 2.0-1; fixed: openvpn 2.0.2-1);
> | Severity: grave; Reported by: Daniel Lehmann <[EMAIL PROTECTED]>;
> | Tags: fixed-upstream, security
> |   Done: Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>;
> | Will be archived in 28 days. 
> Does this mean that the bug will be archived even though it's not
> fixed in sarge?

Hrm. Yes it does, and yes you should manually tag it +sarge if you
don't want that behaviour.

Technically, that can be changed -- expiry isn't actually reimplemented
yet; and I guess it wouldn't be impossible to say "don't expire bugs
that are open in stable and have either  or  tags".

I'd kind-of hope it wouldn't be an issue in practice -- security bugs
that're fixed in unstable ought to have the fix for stable uplaoded
within 28 days anyway, shouldn't they?

Cheers,
aj


signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Anthony Towns]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> Also I don't think that "Patched" as a description for tag 'patch' is 
> correct. The bug has not been patched, there just is a _proposed_ patch 
> available. There is no certainty that the patch is either correct or will 
> be accepted by the maintainer.

If it's known to be incorrect or the maintainer's not going to accept
it, the patch tag isn't appropriate:

A patch or some other easy procedure for fixing the bug is included
in the bug logs. If there's a patch, but it doesn't resolve the bug
adequately or causes some other problems, this tag should not be
used.

> What do others think of the new, extended subdivision of bugs?
> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

The idea is that a maintainer can divide bugs by the actions needed:

* patch: apply the patch, build, test, upload
* moreinfo: no action -- waiting for more info
* wontfix: no action -- won't fix anyway
* unclassified: reproduce, analyse, come up with solutions
* confirmed: analyse, come up with solutions

Bugs tagged "help", "unreproducible", and "upstream" aren't separated
out from unclassified at the moment; maybe "confirmed" shouldn't be
split from unclassified.

Thanks for the polite feedback, it's appreciated.

For those who preferred the bugs not broken up, visit

http://bugs.debian.org/cgi-bin/cookies.cgi?oldview=yes

Cheers,
aj



signature.asc
Description: Digital signature

Re: Version tracking in the BTS

[Hamish Moffatt]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:
> What do others think of the new, extended subdivision of bugs?
> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

Generally I think it's quite useful. However, and slightly off the
topic, how did we end up with "Done bugs"? "Resolved bugs" reads well but
done does not. "Closed" would also work, if you want to use a term that
is an exact BTS command.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Mark Brown]

On Mon, Aug 29, 2005 at 08:50:24PM +0200, Frans Pop wrote:

> What do others think of the new, extended subdivision of bugs?

In general more control of the sorting would be nicer.  Right now
there's an awful lot of categories which I'm finding makes bug listings
a lot more cluttered without adding sufficiently useful information.  I
think this is just that the classification chosen by the BTS isn't quite
what I'm looking for but what I'm looking for is likely to change based
on what I'm doing.

I'm not sure separating out the confirmed tag is such a useful thing,
especially given that it sorts so far up.  Given the use of tags it'd
also seem logical to sort the upstream tag and the forwarded bugs
together.

A way to for a maintainer separate out bug reports that they've not much
intention of doing anything with in the immediate future would be
something I'd personally like to see.

> Personally I don't see enough difference in status between "unclassified" 
> and "moreinfo" to warrant separating them.

I do find that one makes some sense - it separates out bugs where the
maintainer is less likely to be able to do anything about.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Florian Weimer]

* Frans Pop:

> Hmm. IMO listing bugs without those tags as "Unclassified" is confusing, 
> especially with the emphasis that is now put on it. It implies that 
> action is required where I think that is not always the case.

A public page listing only "unclassified" bugs also suggests that
there are private, "classified" bugs.  We know that this
interpretation is wrong, but a cursory reader might not.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 20:31, martin f krafft wrote:
> also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.29.2022 +0200]:
> These classes reflect the tags on the bugs therein.
>   "Patched"
>   "More information needed"
>   "Will not fix"
>   ...

Hmm. IMO listing bugs without those tags as "Unclassified" is confusing, 
especially with the emphasis that is now put on it. It implies that 
action is required where I think that is not always the case.

Also I don't think that "Patched" as a description for tag 'patch' is 
correct. The bug has not been patched, there just is a _proposed_ patch 
available. There is no certainty that the patch is either correct or will 
be accepted by the maintainer.
I would sooner accept a description of "Patched" for 'pending'.

What do others think of the new, extended subdivision of bugs?
Personally I don't see enough difference in status between "unclassified" 
and "moreinfo" to warrant separating them.


pgp3ZmAokPhlI.pgp
Description: PGP signature

Re: Version tracking in the BTS

[Andreas Barth]

* Florian Weimer ([EMAIL PROTECTED]) [050829 20:39]:
> Oh, this seems to imply that security bugs must be tagged sarge
> manually, otherwise the bug will soon disappear from the radar
> screen. 8-(
> 
> Is it acceptable if this tag is set by non-maintainers?

yes.


Cheers,
Andi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Florian Weimer]

* martin f. krafft:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
>> Which tags are used for classification? sarge et al.?  Would it make
>> sense to tag a bug "sarge" if it is reported against the version in
>> sarge (even though this is technically incorrect)?
>
> Please read the announcement about the new meaning of these tags:
>
>   http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

Oh, this seems to imply that security bugs must be tagged sarge
manually, otherwise the bug will soon disappear from the radar
screen. 8-(

Is it acceptable if this tag is set by non-maintainers?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[martin f krafft]

also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.2028 +0200]:
> Which tags are used for classification? sarge et al.?  Would it make
> sense to tag a bug "sarge" if it is reported against the version in
> sarge (even though this is technically incorrect)?

Please read the announcement about the new meaning of these tags:

  http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"i've got a bike,
 you can ride it if you like,
 it's got a basket. a bell that rings, and things to make it look good.
 i'd give it to you if i could,
 but i borrowed it."
  -- syd barrett, 1967


signature.asc
Description: Digital signature (GPG/PGP)

Re: Version tracking in the BTS

[martin f krafft]

also sprach Frans Pop <[EMAIL PROTECTED]> [2005.08.29.2022 +0200]:
> What is "Unclassified" all about?

These classes reflect the tags on the bugs therein.

  "Patched"
  "More information needed"
  "Will not fix"
  ...

I am not sure what happens when there's a +patch+wontfix.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
micro$oft windows psychic edition:
we will tell you where you are going tomorrow.


signature.asc
Description: Digital signature (GPG/PGP)

Re: Version tracking in the BTS

[Florian Weimer]

* Mark Brown:

> On Mon, Aug 29, 2005 at 08:22:32PM +0200, Frans Pop wrote:
>> On Monday 29 August 2005 20:12, martin f krafft wrote:
>> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable
>
>> What is "Unclassified" all about?
>
> No tags that it chooses to use for classification.

Which tags are used for classification? sarge et al.?  Would it make
sense to tag a bug "sarge" if it is reported against the version in
sarge (even though this is technically incorrect)?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Mark Brown]

On Mon, Aug 29, 2005 at 08:22:32PM +0200, Frans Pop wrote:
> On Monday 29 August 2005 20:12, martin f krafft wrote:
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

> What is "Unclassified" all about?

No tags that it chooses to use for classification.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[Frans Pop]

On Monday 29 August 2005 20:12, martin f krafft wrote:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

What is "Unclassified" all about?


pgp7ADUQqwFW9.pgp
Description: PGP signature

Re: Version tracking in the BTS

[Florian Weimer]

* martin f. krafft:

> also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.1957 +0200]:
>> 2.0-1 is the sarge version, but the report has been closed
>> nevertheless.
>
> That's all good and well. It still shows up as outstanding when you
> apply the sarge filter:
>
>   
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

Would it be possible to include such information in the bug-specific
page as well, or at least a link to obtain it?

The summarized output with the sarge filter is somewhat confusing as
well:

| Outstanding bugs -- Grave; Unclassified (1 bug)
| 
| * #324167: OpenVPN 2.0-1 vulnerabilities
|   Package: openvpn (openvpn 2.0-1; fixed: openvpn 2.0.2-1);
| Severity: grave; Reported by: Daniel Lehmann <[EMAIL PROTECTED]>;
| Tags: fixed-upstream, security
|   Done: Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>;
| Will be archived in 28 days. 

Does this mean that the bug will be archived even though it's not
fixed in sarge?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version tracking in the BTS

[martin f krafft]

also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.29.1957 +0200]:
> 2.0-1 is the sarge version, but the report has been closed
> nevertheless.

That's all good and well. It still shows up as outstanding when you
apply the sarge filter:

  
http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=openvpn&archive=no&version=&dist=stable

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"if ever somethin' don't feel right to you, remember what pancho said
 to the cisco kid...  `let's went, before we are dancing at the end of
 a rope, without music.'"
 -- sailor


signature.asc
Description: Digital signature (GPG/PGP)