Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-16 Thread Julian Gilbey
On Thu, Nov 16, 2006 at 12:56:32AM -0500, Theodore Tso wrote:
 On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
  
  Thinking of changing the default behaviour of the devscripts bts show
  (aka bts bugs) command, and want to ask for opinions before I do so.
  
  The BTS behaviour of http://bugs.debian.org/package has recently
  changed.  It used to resolve to:
  
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package
  
  which listed all open and closed bugs in the package, without any
  version tracking being taking into consideration in the listings.
  
  It now resolves to:
  
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable
  
  which lists the status of all bugs in that package in respect to the
  version(s) of the package currently in unstable.
 
 I prefer the new behaviour, myself.  If it must be changed, can it be
 configurable via some kind of .btsrc file? 

Given the second half of your post, please let me clarify the new
behaviour for you.

I fixed bug#396232 in devscripts version 2.9.24.  But when I went to
http://bugs.debian.org/devscripts, it listed this bug among the open
bugs.  Why?  Because m68k or some other arch had not yet autobuilt
version 2.9.24 and was still on 2.9.22.  However, the
non-version-tracking page showed this bug as fixed.

I'm not sure I'd like to make it configurable, as that could lead to
much confusion and error.  It is not particularly difficult to type
'dist=unstable' after the package name if that is truly what you want
(which, I believe, is not likely to be the case for many
maintainers).

 Also, can we please have this functionality for bts cache?  It takes
 a *long* time to download a huge whackload of bugs, many/most of which
 are already fixed in unstable, and so don't matter to me at all.

Do you mean bug#340259?  If you have a patch, please send it to that
bug.

   Julian


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-16 Thread Julian Gilbey
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
 On Sun, 12 Nov 2006, Kurt Roeckx wrote:
  When using bts show package or going to
  http://bugs.debian.org/package; we get that behaviour, and I find
  both of them annoying.
 
 I switched the default to appending dist=untable because it actually
 tells you which bugs affect unstable; it's far more informative than
 merely categorizing based on whether a bug has been closed. If you
 know you want something else, you really should be using the precise
 url that you want.

What I would then really like in this case is for the BTS to have a
category on the list of package bugs called Pending autobuilding or
something like that when asked for dist=unstable with no version
number.  This would be for the situation where the bug is fixed by
version 1.1-4, but some architectures are still on version 1.1-3.  (As
a parallel, if I mark a bug as pending, it disappears from the list
of normal bugs and it is moved into a separate category.  This is
really helpful for knowing at a glance what is going on.)

That, it seems to me, would be the best solution for most of the
issues raised here.  It does not seem possible to easily do this at
the moment.

   Julian


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-16 Thread Damián Viano
On Thu, Nov 16, 2006 at 09:57:21AM +, Julian Gilbey wrote:
 On Thu, Nov 16, 2006 at 12:56:32AM -0500, Theodore Tso wrote:
  On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
   
   Thinking of changing the default behaviour of the devscripts bts show
   (aka bts bugs) command, and want to ask for opinions before I do so.
   
   The BTS behaviour of http://bugs.debian.org/package has recently
   changed.  It used to resolve to:
   
   http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package
   
   which listed all open and closed bugs in the package, without any
   version tracking being taking into consideration in the listings.
   
   It now resolves to:
   
   http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable
   
   which lists the status of all bugs in that package in respect to the
   version(s) of the package currently in unstable.
  
  I prefer the new behaviour, myself.  If it must be changed, can it be
  configurable via some kind of .btsrc file? 

I'd like the new behaviour better also.

 Given the second half of your post, please let me clarify the new
 behaviour for you.
 
 I fixed bug#396232 in devscripts version 2.9.24.  But when I went to
 http://bugs.debian.org/devscripts, it listed this bug among the open
 bugs.  Why?  Because m68k or some other arch had not yet autobuilt
 version 2.9.24 and was still on 2.9.22.  However, the
 non-version-tracking page showed this bug as fixed.

Yes, this is IMHO a little drawback, but doesn't seem terrible to me,
and I also consider good that maintainers are aware that the bugs are
not yet close on all archs.

There has been comments whether the default unstable view should take
into consideration only release-archs or not, that's another topic but
might be related if you are mostly annoyed by non-release candidate
archs.

 I'm not sure I'd like to make it configurable, as that could lead to
 much confusion and error.  It is not particularly difficult to type
 'dist=unstable' after the package name if that is truly what you want
 (which, I believe, is not likely to be the case for many
 maintainers).

I think that for the regular DD (IANADD yet, but I am maintainer)
typing dist=unstable every time they need to use bts IS annoying, so
yes a configurable option is the least I would humbly expect.

You do have a point in maintaining previous behaviour, but I also
think that keeping idempotent 'bts show' and http://p.d.o/packages is at
least for me a valuable thing, since I use them as equivalents.

Either way, thanks for your work on bts, it rocks!

-- 
Damián Viano(Des)  ¯ ¯ - _   _ - ¯ ¯
GPG: 0x6EB95A6F Debian ¯-_GNU_-¯ Linux
Web: http://damianv.com.ar/   ¯-¯


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-16 Thread Julian Gilbey
On Thu, Nov 16, 2006 at 09:27:59AM -0300, Damián Viano wrote:
  I fixed bug#396232 in devscripts version 2.9.24.  But when I went to
  http://bugs.debian.org/devscripts, it listed this bug among the open
  bugs.  Why?  Because m68k or some other arch had not yet autobuilt
  version 2.9.24 and was still on 2.9.22.  However, the
  non-version-tracking page showed this bug as fixed.
 
   Yes, this is IMHO a little drawback, but doesn't seem terrible to me,
 and I also consider good that maintainers are aware that the bugs are
 not yet close on all archs.
 
   There has been comments whether the default unstable view should take
 into consideration only release-archs or not, that's another topic but
 might be related if you are mostly annoyed by non-release candidate
 archs.

I'm not so much annoyed by any particular arch, but if I want to see
which bug I should work on next, I'm annoyed when bugs I've already
fixed reappear in the Normal bugs list.  In a separate email I've
suggested that it would be good to have a separate category for
Pending autobuilding or something for such bugs.

   Julian


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-16 Thread Don Armstrong
On Thu, 16 Nov 2006, Julian Gilbey wrote:
 On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
  On Sun, 12 Nov 2006, Kurt Roeckx wrote:
   When using bts show package or going to
   http://bugs.debian.org/package; we get that behaviour, and I find
   both of them annoying.
  
  I switched the default to appending dist=untable because it actually
  tells you which bugs affect unstable; it's far more informative than
  merely categorizing based on whether a bug has been closed. If you
  know you want something else, you really should be using the precise
  url that you want.
 
 What I would then really like in this case is for the BTS to have a
 category on the list of package bugs called Pending autobuilding or
 something like that when asked for dist=unstable with no version
 number.

It would be possible to separate out bugs that are fixed on one arch,
but unfixed on others when viewing a particular distribution; the only
thing that people have to be aware of is that it doesn't necessarily
mean that those bugs will be fixed automatically... but presumably
FTBFS bugs will be filed if they don't.

It may also be more useful to indicate whether a bug is actually fixed
in a set of distributions/archs with some sort of summary field
instead of relying on the categorization to do that... I'll try to
think about it over some beer later on today.


Don Armstrong

-- 
This message brought to you by weapons of mass destruction related
program activities, and the letter G.

http://www.donarmstrong.com  http://rzlab.ucr.edu


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-15 Thread Theodore Tso
On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
 
 Thinking of changing the default behaviour of the devscripts bts show
 (aka bts bugs) command, and want to ask for opinions before I do so.
 
 The BTS behaviour of http://bugs.debian.org/package has recently
 changed.  It used to resolve to:
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package
 
 which listed all open and closed bugs in the package, without any
 version tracking being taking into consideration in the listings.
 
 It now resolves to:
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable
 
 which lists the status of all bugs in that package in respect to the
 version(s) of the package currently in unstable.

I prefer the new behaviour, myself.  If it must be changed, can it be
configurable via some kind of .btsrc file? 

Also, can we please have this functionality for bts cache?  It takes
a *long* time to download a huge whackload of bugs, many/most of which
are already fixed in unstable, and so don't matter to me at all.

- Ted


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-13 Thread Kurt Roeckx
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
 On Sun, 12 Nov 2006, Kurt Roeckx wrote:
  When using bts show package or going to
  http://bugs.debian.org/package; we get that behaviour, and I find
  both of them annoying.
 
 I switched the default to appending dist=untable because it actually
 tells you which bugs affect unstable; it's far more informative than
 merely categorizing based on whether a bug has been closed. If you
 know you want something else, you really should be using the precise
 url that you want.

So, the default is basicly for the maintainer of the package, so they can
see what bugs they need to fix in unstable?

Users on the other hand might be more interested in the bugs affecting
stable (or testing).  It seems more logical to just lists all bugs for
them.


Kurt


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-13 Thread Don Armstrong
On Mon, 13 Nov 2006, Kurt Roeckx wrote:
 On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
  On Sun, 12 Nov 2006, Kurt Roeckx wrote:
   When using bts show package or going to
   http://bugs.debian.org/package; we get that behaviour, and I find
   both of them annoying.
  
  I switched the default to appending dist=untable because it actually
  tells you which bugs affect unstable; it's far more informative than
  merely categorizing based on whether a bug has been closed. If you
  know you want something else, you really should be using the precise
  url that you want.
 
 So, the default is basicly for the maintainer of the package, so
 they can see what bugs they need to fix in unstable?

Or for anyone else looking at unstable, so you can see what bugs
affect unstable. Otherwise, the categorization is done based on
whether a message has been sent to -done or not, and tells you nothing
about whether the bug is actually fixed in any version that is
actually distributed.

Moreover, it also means that you see bugs as unfixed which do not
affect the current version of the package (for example, those bugs
which only affect stable which the unstable package is not a decendant
of. [See #373930 for an example;
http://bugs.donarmstrong.com/cgi-bin/version.cgi?package=libc6;found=glibc%2F2.3.2.ds1-22sarge3;ignore_boring=0
if you don't see imediately why unstable isn't affected.]

 Users on the other hand might be more interested in the bugs
 affecting stable (or testing). It seems more logical to just lists
 all bugs for them.

All of the bugs are listed; this merely changes the categories that
they are placed in. [And I submit that users who care what bugs affect
stable and/or testing should be using complete urls to pkgreport.cgi
instead of the 'leet urls.]
 

Don Armstrong

-- 
Of course Pacman didn't influence us as kids. If it did, we'd be
running around in darkened rooms, popping pills and listening to
repetitive music.

http://www.donarmstrong.com  http://rzlab.ucr.edu


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Loïc Minier
On Sun, Nov 12, 2006, Julian Gilbey wrote:
 Thinking of changing the default behaviour of the devscripts bts show
 (aka bts bugs) command, and want to ask for opinions before I do so.

 Perhaps you can use versions instead?
 http://bugs.debian.org/foo;version=x.y resolves to pkgreport with
 pkg=foo, version=x.y, and dist=unstable, and shows the bugs as closed
 if these were closed with version=x.y.

-- 
Loïc Minier [EMAIL PROTECTED]


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Kurt Roeckx
On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
 Hi all!
 
 Thinking of changing the default behaviour of the devscripts bts show
 (aka bts bugs) command, and want to ask for opinions before I do so.
[...]
 It now resolves to:
 
 http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable

When using bts show package or going to
http://bugs.debian.org/package; we get that behaviour, and I find both
of them annoying.

Some other thing it does now is that if I file a bug against a package
before the bts knows about it, it shows up as in other versions or
something.

I think the default of the bts when going to
http://bugs.debian.org/package should change back to the old behaviour,
and you shouldn't change the bts command.

Some other behaviour of the BTS I'm annoyed about is the order in which
it shows bugs without a way for me to show them in the order I want.
I've actually filed a bug about that: #356270


Kurt


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Don Armstrong
On Sun, 12 Nov 2006, Kurt Roeckx wrote:
 When using bts show package or going to
 http://bugs.debian.org/package; we get that behaviour, and I find
 both of them annoying.

I switched the default to appending dist=untable because it actually
tells you which bugs affect unstable; it's far more informative than
merely categorizing based on whether a bug has been closed. If you
know you want something else, you really should be using the precise
url that you want.

 Some other thing it does now is that if I file a bug against a
 package before the bts knows about it, it shows up as in other
 versions or something.

You should be hard pressed to be able to actually install packages
before the BTS has learned about the version unless you're filing bugs
on packages which you've built yourself. [Far more likely that the
version the bug is filed against is wrong.]


Don Armstrong

-- 
Any excuse will serve a tyrant.
 -- Aesop

http://www.donarmstrong.com  http://rzlab.ucr.edu


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Julian Gilbey
On Sun, Nov 12, 2006 at 12:19:30PM +0100, Kurt Roeckx wrote:
 On Sun, Nov 12, 2006 at 01:02:06AM +, Julian Gilbey wrote:
  Hi all!
  
  Thinking of changing the default behaviour of the devscripts bts show
  (aka bts bugs) command, and want to ask for opinions before I do so.
 [...]
  It now resolves to:
  
  http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable
 
 When using bts show package or going to
 http://bugs.debian.org/package; we get that behaviour, and I find both
 of them annoying.
 [...]
 
 I think the default of the bts when going to
 http://bugs.debian.org/package should change back to the old behaviour,
 and you shouldn't change the bts command.

To clarify: I have no control over the BTS itself, and Don Armstrong
rejected my request for the default http://bugs.debian.org/package
behaviour to revert to its old behaviour (see
http://bugs.debian.org/397925).  So the only thing within my ability
is to change the devscripts bts command so that it behaves in the way
it used to before the BTS change.

   Julian


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Henrique de Moraes Holschuh
On Sun, 12 Nov 2006, Julian Gilbey wrote:
 http://bugs.debian.org/397925).  So the only thing within my ability
 is to change the devscripts bts command so that it behaves in the way
 it used to before the BTS change.

Could you make it configurable?  I like the show unstable bugs behaviour
far more for my DD work...  but I can easily see how a show stable bugs
behaviour would make more sense for the packages goint into Etch now...

-- 
  One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie. -- The Silicon Valley Tarot
  Henrique Holschuh


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Julian Gilbey
On Sun, Nov 12, 2006 at 01:15:21PM -0200, Henrique de Moraes Holschuh wrote:
 On Sun, 12 Nov 2006, Julian Gilbey wrote:
  http://bugs.debian.org/397925).  So the only thing within my ability
  is to change the devscripts bts command so that it behaves in the way
  it used to before the BTS change.
 
 Could you make it configurable?  I like the show unstable bugs behaviour
 far more for my DD work...  but I can easily see how a show stable bugs
 behaviour would make more sense for the packages goint into Etch now...

Current bts can do this:

bts show package dist=unstable
bts show package dist=testing

The only question is about the default behaviour of bts show package.

   Julian


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



Re: RFC: behaviour of bts show command with new BTS default behaviour

2006-11-12 Thread Kurt Roeckx
On Sun, Nov 12, 2006 at 03:50:46AM -0800, Don Armstrong wrote:
  Some other thing it does now is that if I file a bug against a
  package before the bts knows about it, it shows up as in other
  versions or something.
 
 You should be hard pressed to be able to actually install packages
 before the BTS has learned about the version unless you're filing bugs
 on packages which you've built yourself. [Far more likely that the
 version the bug is filed against is wrong.]

As buildd admin, I can file bugs at the moment I get the buildd log, and
so can other buildd admins and people who get the logs.

At that time, the bts will not know about that version yet, but it does
exists.

This is also very simular to packages that just get out of NEW.


Kurt


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



RFC: behaviour of bts show command with new BTS default behaviour

2006-11-11 Thread Julian Gilbey
Hi all!

Thinking of changing the default behaviour of the devscripts bts show
(aka bts bugs) command, and want to ask for opinions before I do so.

The BTS behaviour of http://bugs.debian.org/package has recently
changed.  It used to resolve to:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package

which listed all open and closed bugs in the package, without any
version tracking being taking into consideration in the listings.

It now resolves to:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=package;dist=unstable

which lists the status of all bugs in that package in respect to the
version(s) of the package currently in unstable.

I was confused by this, because bugs which I had just closed through
an upload were still shown as open, because the autobuilders hadn't
yet built the newest version on all architectures.  But it does not
show bugs only relating to experimental or stable versions.

I would like to change the default behaviour of the bts show command,
when used as bts show package or bts show maintainer to behave
as it used to do, by manually rewriting the URL to the earlier form
before downloading.

Before I make this change, I'd like feedback, please; if it's
unpopular, I won't do it.

   Julian


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