Re: Wanted BTS feature: subscription to individual bug reports

2004-10-14 Thread Nikita V. Youshchenko


 Anand Kumria [EMAIL PROTECTED]:
 On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
  I can't find a way to track more-or-less easilly all bugs in BTS that 
I
  am somewhat involved into.
  
 
 If by 'involved' you mean submitted, then this might be useful:
 
 
URL:http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]
 
 I assume he mean also bugs on wich he had supplied additional
 information. 

Yes.
Also, such BTS query just lists the report.
What I want is immidiate notify on any additional posting to any of those 
reports. The best - a copy of that posting in my mailbox.

Well, a script to pool BTS periodically, so the problem has a personal 
solution. But I think individual bug subscription is useful enough to be 
implemented at BTS level.




Re: Wanted BTS feature: subscription to individual bug reports

2004-10-13 Thread Anand Kumria
On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:

 Hello.
 
 I can't find a way to track more-or-less easilly all bugs in BTS that I am 
 somewhat involved into.
 

If by 'involved' you mean submitted, then this might be useful:

URL:http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]

Cheers,
Anand

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!





Re: Wanted BTS feature: subscription to individual bug reports

2004-10-13 Thread Wouter Verhelst
On Thu, Oct 14, 2004 at 01:59:36AM +1000, Anand Kumria wrote:
 On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
 
  Hello.
  
  I can't find a way to track more-or-less easilly all bugs in BTS that I am 
  somewhat involved into.
  
 
 If by 'involved' you mean submitted, then this might be useful:
 
 URL:http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]

Or, if you want the short version:

http://bugs.debian.org/from:[EMAIL PROTECTED]

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature


Re: Wanted BTS feature: subscription to individual bug reports

2004-10-13 Thread Erik Schanze
Anand Kumria [EMAIL PROTECTED]:
 On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote:
  I can't find a way to track more-or-less easilly all bugs in BTS that I am 
  somewhat involved into.
  
 
 If by 'involved' you mean submitted, then this might be useful:
 
 URL:http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]
 
I assume he mean also bugs on wich he had supplied additional information.
This feature would be very nice.

Regards,

Erik


-- 
 www.ErikSchanze.de *
 Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
  * Linux-Info-Tag in Dresden, am 30. Oktober 2004  *
 Info: http://www.linux-info-tag.de *




Wanted BTS feature: subscription to individual bug reports

2004-10-12 Thread Nikita V. Youshchenko
Hello.

I can't find a way to track more-or-less easilly all bugs in BTS that I am 
somewhat involved into.

Currently I can subscribe to bugs on per-package-basis (using PTS), or to 
all bugs using [EMAIL PROTECTED]

Something thar could be really usable is subscribing to bugs that I've 
either submitted, or ever posted a comment to.

Is something like that available/planned?




Re: Wanted BTS feature: subscription to individual bug reports

2004-10-12 Thread Christoph Berg
Re: Nikita V. Youshchenko in [EMAIL PROTECTED]
 I can't find a way to track more-or-less easilly all bugs in BTS that I am 
 somewhat involved into.
 
 Is something like that available/planned?

Planned yes, available no:

http://people.debian.org/~terpstra/message/20030918.123817.598830d5.en.html

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature


BTS feature?

2001-05-01 Thread Brian May
Hello,

during the latest debate on the BTS, I thought of a new feature
which would be really useful in the BTS.

Instead of the maintainer sending a message to
bugid[EMAIL PROTECTED] saying this is not a bug (which only
serves to annoy submitters who are convinced otherwise), you should be
able to send a message to bugid[EMAIL PROTECTED]

The BTS system would automatically close the bug if nothing else is
received, say within 30 days. If something is received, then the
autoclose is cancelled, and the bug remains open.

Same for responses of the type if I don't hear from you, I will
assume this bug has been fixed. I think it would be nice if this
could get automated.

Comments?
-- 
Brian May [EMAIL PROTECTED]




Re: BTS feature?

2001-05-01 Thread Steve M. Robbins
On Tue, May 01, 2001 at 03:38:06PM +1000, Brian May wrote:
 Hello,
 
 during the latest debate on the BTS, I thought of a new feature
 which would be really useful in the BTS.
 
 Instead of the maintainer sending a message to
 bugid[EMAIL PROTECTED] saying this is not a bug (which only
 serves to annoy submitters who are convinced otherwise), you should be
 able to send a message to bugid[EMAIL PROTECTED]
 
 The BTS system would automatically close the bug if nothing else is
 received, say within 30 days. If something is received, then the
 autoclose is cancelled, and the bug remains open.

I don't follow your reasoning.  Are you suggesting that the bug submitters
will be less annoyed if the bug is closed after 30 days, rather than
immediately?  Why would that be?

-S




Re: BTS feature?

2001-05-01 Thread John Hasler
Steve M. Robbins writes:
 I don't follow your reasoning.  Are you suggesting that the bug
 submitters will be less annoyed if the bug is closed after 30 days,
 rather than immediately?  Why would that be?

Many bug submitters never respond to requests for additional information.
Example: let's say I receive a bug against pppconfig which says I typed
pon and nothing happened!.  I conclude that it is probably operator error
and send a request for clarification to bugid[EMAIL PROTECTED]
In the meantime the submitter gets around to reading the pon man page and
realizes that his connection was up all the time.  He is so embarrassed
that he doesn't respond.  Consequently, at the end of 30 days the bug goes
away by itself.  Had he responded to my request, the bug would have become
permanent and I would have to deal with it.

I would think that this autoclose feature would be quite popular with
maintainers of packages that receive large numbers of spurious or duplicate
bug reports.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin




Re: BTS feature?

2001-05-01 Thread Matt Zimmerman
On Tue, May 01, 2001 at 11:51:39AM -0500, John Hasler wrote:

 Steve M. Robbins writes:
  I don't follow your reasoning.  Are you suggesting that the bug
  submitters will be less annoyed if the bug is closed after 30 days,
  rather than immediately?  Why would that be?
 
 Many bug submitters never respond to requests for additional information.
 Example: let's say I receive a bug against pppconfig which says I typed
 pon and nothing happened!.  I conclude that it is probably operator error
 and send a request for clarification to bugid[EMAIL PROTECTED]
 In the meantime the submitter gets around to reading the pon man page and
 realizes that his connection was up all the time.  He is so embarrassed
 that he doesn't respond.  Consequently, at the end of 30 days the bug goes
 away by itself.  Had he responded to my request, the bug would have become
 permanent and I would have to deal with it.
 
 I would think that this autoclose feature would be quite popular with
 maintainers of packages that receive large numbers of spurious or duplicate
 bug reports.

The 'moreinfo' BTS tag already exists for this purpose.  If manually looking
for this tag is too much work (hmm...), then a simple script could be written
to find bugs with this tag that have not seen any activity in a certain amount
of time.

-- 
 - mdz




Re: BTS feature?

2001-05-01 Thread Brian May
 Steve == Steve M Robbins [EMAIL PROTECTED] writes:

Steve I don't follow your reasoning.  Are you suggesting that the
Steve bug submitters will be less annoyed if the bug is closed
Steve after 30 days, rather than immediately?  Why would that be?

Instead of forcing maintainers to keep the bug open, say for thirty
days, and manually close the bug, this is done automatically.

Many times, the maintainer has not bothered, and simply closed the bug
immediately.

In the first case, the submitter can response and say Yes, it is a
bug. Here is why In the second case, the submitter must reopen
the bug, and potentially get into a flamewar other if the bug should
be open or closed.

Or put another way, the maintainer can effectively say: if you don't
respond within 30 days, I will close this bug, but without having to
manually keep track of 30 days if he doesn't get any response.
-- 
Brian May [EMAIL PROTECTED]




Re: BTS feature comments

1999-09-25 Thread Nicolás Lichtmaier
 About security on the BTS:

 Don't introduce a system with `pre-security', let's use `post-security'...
what do I mean? The following: Make every action undoable and advertised,
e.g.: if someone manipulates a bug in any way the maintainer gets an email.
I think that that's how it's working now, so... don't touch it.. =)



Re: BTS feature comments

1999-09-24 Thread Wichert Akkerman
Previously Darren Benham wrote:
 - Forwarded message from Samuel Tardieu [EMAIL PROTECTED] -
 | And do what... there are going to be keys that aren't in the debian 
 keyring..

The reason I mentioned this on a bugreport was that it would be very
easy to check if a signature is correct if we have the key available.
From there it would be easy to make it only possible for developers
to modify the BTS if we want to go that way, but right now I'm not
convinced we should go that way.

Wichert.

-- 
==
This combination of bytes forms a message written to you by Wichert Akkerman.
E-Mail: [EMAIL PROTECTED]
WWW: http://www.wi.leidenuniv.nl/~wichert/


pgpf2DhDMwzMB.pgp
Description: PGP signature


Re: BTS feature comments

1999-09-24 Thread Josip Rodin
On Thu, Sep 23, 1999 at 08:35:06AM -0700, Darren Benham wrote:
  | And do what... there are going to be keys that aren't in the debian 
  keyring..
  
  Non-developpers should not be allowed to *manipulate* bugs IMO.
 
 What do you think?

Make me PGP/GPG/whatever sign all messages I send to [EMAIL PROTECTED], and
I shall become your mortal enemy : :)

Next step would be signing everything sent to the BTS, then everything
sent to debian-* mailing lists... please, don't.

If anyone puts trash in the BTS because there is no authentication,
we'll handle it. I'll even volunteer to clean it up.

-- 
enJoy -*/\*- don't even try to pronounce my first name



BTS feature comments

1999-09-23 Thread Darren Benham
What do you think?
- Forwarded message from Samuel Tardieu [EMAIL PROTECTED] -


On 21/09, Darren Benham wrote:

| And do what... there are going to be keys that aren't in the debian keyring..

Non-developpers should not be allowed to *manipulate* bugs IMO.



- End forwarded message -


pgpMQch7Kmr7I.pgp
Description: PGP signature


Re: BTS feature comments

1999-09-23 Thread J.H.M. Dassen \(Ray\)
On Thu, Sep 23, 1999 at 08:35:06 -0700, Darren Benham wrote:
 - Forwarded message from Samuel Tardieu [EMAIL PROTECTED] -
 Non-developpers should not be allowed to *manipulate* bugs IMO.

It would be nice to have a mechanism available to ensure this if there is
indeed abuse of the BTS by non-developers; so far I haven't seen it, and I
see no reason e.g. to prevent users from merging bug reports when they
notice something has been reported already.

Ray
-- 
LEADERSHIP  A form of self-preservation exhibited by people with auto-
destructive imaginations in order to ensure that when it comes to the crunch 
it'll be someone else's bones which go crack and not their own.   
- The Hipcrime Vocab by Chad C. Mulligan



Re: BTS feature comments

1999-09-23 Thread Marcelo E. Magallon
 Darren Benham [EMAIL PROTECTED] writes:

  What do you think?

well, for one, the submitter doesn't have to be a developer, and it's
perfectly ok for the submitter to manipulate his bugs.  I've always
thought the rule only the maintainer and the submitter are allowed to close
bugs to be a good one.  In fact, as a submitter I've closed or reassigned
bugs several times...  as a maintainer, I've found some bugs have been
reassigned or closed by the submitter, and I was pleased about it...

  On 21/09, Darren Benham wrote:
  
  | And do what... there are going to be keys that aren't in the debian 
  keyring..
  
  Non-developpers should not be allowed to *manipulate* bugs IMO.

why would I start marking bugs in, say xfree, as fixed if I'm not the
maintainer.  I asked Branden about this once, and *he* asked me to submit
reports to the corresponding bugs and, iirc, mark them fixed.  But in that
situation I had permission from the maintainer, which is a good thing.


Marcelo



Re: BTS feature comments

1999-09-23 Thread Daniel Burrows
On Thu, Sep 23, 1999 at 08:35:06AM -0700, Darren Benham was heard to say:
 What do you think?
 - Forwarded message from Samuel Tardieu [EMAIL PROTECTED] -
 
 
 On 21/09, Darren Benham wrote:
 
 | And do what... there are going to be keys that aren't in the debian 
 keyring..
 
 Non-developpers should not be allowed to *manipulate* bugs IMO.
 
 
 
 - End forwarded message -

  As a non-developer who has manipulated bugs..

  I think that non-developers should be allowed to manipulate bugs that they
are the submittors of.  Several times now I've submitted bugs that either
became outdated by a new release or turned out to be my own fault (eg, I
reported a bug against lftp that was caused because a local install in
/usr/local/bin which I had forgotten about was overriding my packaged
installation in /usr/bin) but nevertheless was not closed -- in such cases, I
generally send a message to (bug-num)@bugs.debian.org saying that the bug is not
a bug anymore and should be closed.  However, in a few cases I never got a
response from the maintainer and decided to just close a bug myself.

  I think that I may once have reopened a bug that I reported when it was
prematurely closed (that is, the maintainer closed it but I could still
reproduce the problem in the supposedly fixed version), in preference to
submitting a new bug report.  I'm not sure about that, though.  I may have just
considered it.

  Are these shooting offenses?  If so, I guess I should start keeping an eye
out for the Debian Hit Squad.. :-/

  Daniel

-- 
  Man is timid; he no longer says 'I think' or 'I am' but quotes some prophet
 or sage.
   -- Ralph Waldo Emerson, Self-Reliance



Re: BTS feature comments

1999-09-23 Thread Samuel Tardieu
|   As a non-developer who has manipulated bugs..

[...]

| a bug anymore and should be closed.  However, in a few cases I never got a
| response from the maintainer and decided to just close a bug myself.

[...]

|   Are these shooting offenses?  If so, I guess I should start keeping an eye
| out for the Debian Hit Squad.. :-/

Of course not, but only the package maintainer is supposed to close bugs on
her package. Even other Debian developers should use the fixed state.

If, as a non-developer, notice a bug that should be closed and have no
request from the maintainer of the package, then you should ask on
debian-devel that someone closes the bug, after checking that the bug
does not exist anymore. And in a perfect life, all the developers should
answer requests in a timely manner.

  Sam


pgpHUjwtWVmmX.pgp
Description: PGP signature


Re: BTS feature comments

1999-09-23 Thread Darren Benham
On Thu, Sep 23, 1999 at 06:23:27PM +0200, Samuel Tardieu wrote:
 Of course not, but only the package maintainer is supposed to close bugs on
 her package. Even other Debian developers should use the fixed state.
 

Unless somebody's changed something while I wasn't looking, Debian accepts
submitters closing bugs they've submitted, also


pgpHk57qFumHr.pgp
Description: PGP signature