|
Home > Archive > Debian Developers > August 2005 > Version tracking in the BTS
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Version tracking in the BTS
|
|
| Florian Weimer 2005-08-29, 6:01 pm |
| Could someone who is familiar with the new BTS have a look at #324167,
please?
The BTS has corectly record this data:
Found in version openvpn/2.0-1;
Fixed in version openvpn/2.0.2-1
2.0-1 is the sarge version, but the report has been closed
nevertheless.
Is it still necessary to manually reopen all security bugs which have
been fixed in a new upload to unstable, but are also present in the
stable distribution?
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-08-29, 6:01 pm |
| * martin f. krafft:
> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.08.29.1957 +0200]:
>
> That's all good and well. It still shows up as outstanding when you
> apply the sarge filter:
>
> http://bugs.debian.org/cgi-bin/pkgr...on=&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 <leh@l3h.de>;
| Tags: fixed-upstream, security
| Done: Alberto Gonzalez Iniesta <agi@inittab.org>;
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-08-29, 6:01 pm |
| also sprach Florian Weimer <fw@deneb.enyo.de> [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/pkgr...on=&dist=stable
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : 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
| |
| Mark Brown 2005-08-29, 6:01 pm |
| 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/pkgr...on=&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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frans Pop 2005-08-29, 6:01 pm |
| | |
| martin f krafft 2005-08-29, 6:01 pm |
| also sprach Florian Weimer <fw@deneb.enyo.de> [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-deve...7/msg00010.html
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft <madduck@debian.org>
: :' : 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
| |
| martin f krafft 2005-08-29, 6:01 pm |
| also sprach Frans Pop <aragorn@tiscali.nl> [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 <madduck@debian.org>
: :' : 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.
| |
| Florian Weimer 2005-08-29, 6:01 pm |
| * Mark Brown:
> On Mon, Aug 29, 2005 at 08:22:32PM +0200, Frans Pop wrote:
>
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-08-29, 6:01 pm |
| * martin f. krafft:
> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.08.29.2028 +0200]:
>
> Please read the announcement about the new meaning of these tags:
>
> http://lists.debian.org/debian-deve...7/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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Andreas Barth 2005-08-29, 6:01 pm |
| * Florian Weimer (fw@deneb.enyo.de) [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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Frans Pop 2005-08-29, 6:01 pm |
| | |
| Florian Weimer 2005-08-29, 6:01 pm |
| * 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Mark Brown 2005-08-29, 6:01 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2005-08-29, 6:01 pm |
| 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 <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-08-30, 2:56 am |
| 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 <leh@l3h.de>;
> | Tags: fixed-upstream, security
> | Done: Alberto Gonzalez Iniesta <agi@inittab.org>;
> | 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 <sarge> or <security> 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
| |
| Anthony Towns 2005-08-30, 2:56 am |
| 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
| |
| Thomas Bushnell BSG 2005-08-30, 2:56 am |
| martin f krafft <madduck@debian.org> writes:
> also sprach Florian Weimer <fw@deneb.enyo.de> [2005.08.29.2028 +0200]:
>
> Please read the announcement about the new meaning of these tags:
>
> http://lists.debian.org/debian-deve...7/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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| martin f krafft 2005-08-30, 2:56 am |
| also sprach Thomas Bushnell BSG <tb@becket.net> [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 <madduck@debian.org>
: :' : 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
| |
| Steve Langasek 2005-08-30, 2:56 am |
| 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.
vorlon@debian.org http://www.debian.org/
| |
| Frans Pop 2005-08-30, 8:15 am |
| | |
| Hamish Moffatt 2005-08-30, 8:15 am |
| 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 <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2005-08-30, 6:01 pm |
| Frans Pop <aragorn@tiscali.nl> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2005-08-30, 6:01 pm |
| Hamish Moffatt <hamish@debian.org> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Javier Fernández-Sanguino Peña 2005-08-30, 6:01 pm |
| On Tue, Aug 30, 2005 at 10:45:47AM -0700, Russ Allbery wrote:
> Frans Pop <aragorn@tiscali.nl> writes:
>
>
>
> 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
| |
| martin f krafft 2005-08-30, 6:01 pm |
| also sprach Javier Fernández-Sanguino Peña <jfs@computer.org> [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 <madduck@debian.org>
: :' : 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
| |
| Helmut Wollmersdorfer 2005-08-30, 6:01 pm |
| Frans Pop wrote:
> On Monday 29 August 2005 21:59, Anthony Towns wrote:
[vbcol=seagreen]
[...][vbcol=seagreen]
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Russ Allbery 2005-08-30, 8:49 pm |
| Helmut Wollmersdorfer <helmut.wollmersdorfer@gmx.at> writes:
> Frans Pop wrote:
[vbcol=seagreen]
> 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 (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2005-08-30, 8:49 pm |
| martin f krafft <madduck@debian.org> writes:
> also sprach Thomas Bushnell BSG <tb@becket.net> [2005.08.30.0729 +0200]:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Anthony Towns 2005-08-31, 2:52 am |
| On Tue, Aug 30, 2005 at 10:45:47AM -0700, Russ Allbery wrote:
> Frans Pop <aragorn@tiscali.nl> writes:
> Something like "patch available" would sound a lot better to me [...]
Changed.
Cheers,
aj
| |
| Scott James Remnant 2005-08-31, 7:51 am |
| 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?
| |
| Steve Langasek 2005-08-31, 7:51 am |
| 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:
[vbcol=seagreen]
> 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.
vorlon@debian.org http://www.debian.org/
| |
| Anthony Towns 2005-08-31, 7:51 am |
| 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
| |
| Adeodato Simó 2005-08-31, 6:01 pm |
| * 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-deve...8/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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
|
|
|
|
|