Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #700598 > unrolled thread

Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2015-12-13 12:10 +0100
    Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place James McCoy <jamessan@debian.org> - 2015-12-17 15:30 +0100
      Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place Nicholas Bamber <nicholas@periapt.co.uk> - 2015-12-17 19:10 +0100
        Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place James McCoy <jamessan@debian.org> - 2015-12-17 20:40 +0100
          Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place Nicholas Bamber <nicholas@periapt.co.uk> - 2015-12-17 22:30 +0100
    Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2015-12-18 00:10 +0100
      Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place Nicholas Bamber <nicholas@periapt.co.uk> - 2015-12-18 00:20 +0100
    Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2015-12-18 00:50 +0100
    Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2015-12-20 18:50 +0100
      Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place James McCoy <jamessan@debian.org> - 2015-12-22 04:40 +0100
    Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place 積丹尼 Dan Jacobson <jidanni@jidanni.org> - 2015-12-22 05:10 +0100

#700598 — Bug#807810: Mention what if one wants to mark the bug forwarded to more than one place

Package: devscripts
Version: 2.15.9
Severity: wishlist
File: /usr/share/man/man1/bts.1.gz

       forwarded bug address
           Mark the bug as forwarded to the given address (usually an email
           address or a URL for an upstream bug tracker).

Mention what if one wants to mark the bug forwarded to more than one place.

[toc] | [next] | [standalone]

#701734

[Multipart message — attachments visible in raw view] — view raw

On Dec 13, 2015 6:06 AM, "積丹尼 Dan Jacobson" <jidanni@jidanni.org> wrote:
>        forwarded bug address
>            Mark the bug as forwarded to the given address (usually an
email
>            address or a URL for an upstream bug tracker).
>
> Mention what if one wants to mark the bug forwarded to more than one
place.

Why should there be more than one place?

If it's a single issue, then there should be a single place to reference.
If there are multiple issues, then the bug should be cloned and each clone
can have their own forwarded reference.

Yes, the forwarded string can contain arbitrary text, so you can have
multiple URLs in it, but when is that actually useful?

Cheers,
James

[toc] | [prev] | [next] | [standalone]

#701760

James,
	I agree that I can see no need to support multiple forwarding 
addresses. However it turns out we currently support that. As a test 
this bug has been forwarded to two locations.

	Currently this bug is asking for that to be documented.

	

On 17/12/15 14:17, James McCoy wrote:
> On Dec 13, 2015 6:06 AM, "積丹尼 Dan Jacobson" <jidanni@jidanni.org
> <mailto:jidanni@jidanni.org>> wrote:
>  >        forwarded bug address
>  >            Mark the bug as forwarded to the given address (usually an
> email
>  >            address or a URL for an upstream bug tracker).
>  >
>  > Mention what if one wants to mark the bug forwarded to more than one
> place.
>
> Why should there be more than one place?
>
> If it's a single issue, then there should be a single place to
> reference. If there are multiple issues, then the bug should be cloned
> and each clone can have their own forwarded reference.
>
> Yes, the forwarded string can contain arbitrary text, so you can have
> multiple URLs in it, but when is that actually useful?
>
> Cheers,
> James
>
>
>
> _______________________________________________
> devscripts-devel mailing list
> devscripts-devel@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/devscripts-devel
>

[toc] | [prev] | [next] | [standalone]

#701777

[Multipart message — attachments visible in raw view] — view raw

On Dec 17, 2015 12:57 PM, "Nicholas Bamber" <nicholas@periapt.co.uk> wrote:
>
> James,
>         I agree that I can see no need to support multiple forwarding
addresses. However it turns out we currently support that.

If by "support", you mean we don't do any verification of what the
"forwarded" string is (and neither does the BTS), then yes we support it.

I wouldn't claim that, though.  It's probably better to just use wording
similar to how the BTS explains it.

    address should generally be a URI, or possibly an email address.  Using
a URI where possible allows tools to query a remote bug tracking system
(such as bugzilla) for a bug's status.

Essentially, "address" can be arbitrary text, but common convention is for
it to be an email address or link.

Cheers,
James

[toc] | [prev] | [next] | [standalone]

#701790

On 17/12/15 19:29, James McCoy wrote:
> On Dec 17, 2015 12:57 PM, "Nicholas Bamber" <nicholas@periapt.co.uk
> <mailto:nicholas@periapt.co.uk>> wrote:
>  >
>  > James,
>  >         I agree that I can see no need to support multiple forwarding
> addresses. However it turns out we currently support that.
>
> If by "support", you mean we don't do any verification of what the
> "forwarded" string is (and neither does the BTS), then yes we support it.
>
> I wouldn't claim that, though.  It's probably better to just use wording
> similar to how the BTS explains it.
>
>      address should generally be a URI, or possibly an email address.
> Using a URI where possible allows tools to query a remote bug tracking
> system (such as bugzilla) for a bug's status.
>
> Essentially, "address" can be arbitrary text, but common convention is
> for it to be an email address or link.
>
> Cheers,
> James
>


I suppose at some point in the future the bugs server might change its 
behaviour. So one could argue that everything is already documented with 
this line in the bts man page:

"For full details about the commands, see the BTS documentation. 
<https://www.debian.org/Bugs/server-control>"

I don't see any particular reason to single out the forwarded command 
for extra documentation.

[toc] | [prev] | [next] | [standalone]

#701805

reassign 807810 bugs.debian.org
thanks
OK I'll reassign this bug, in the hope that on
https://www.debian.org/Bugs/server-control they will add some policy
statement about what to do when one wants to mark a bug forwarded to
more than one place, for whatever unexpected reason that might come up.

NB> I suppose at some point in the future the bugs server might change its
NB> behaviour. So one could argue that everything is already documented
NB> with this line in the bts man page:

NB> "For full details about the commands, see the BTS documentation.
NB> <https://www.debian.org/Bugs/server-control>"

NB> I don't see any particular reason to single out the forwarded command
NB> for extra documentation.

[toc] | [prev] | [next] | [standalone]

#701806

I don't think that quite follows. I was not suggesting that 
bugs.debian.org change anything. But they might lock it down in the 
future. So if we document precisely how things work now we would be 
overdocumenting the system.


On 17/12/15 23:05, 積丹尼 Dan Jacobson wrote:
> reassign 807810 bugs.debian.org
> thanks
> OK I'll reassign this bug, in the hope that on
> https://www.debian.org/Bugs/server-control they will add some policy
> statement about what to do when one wants to mark a bug forwarded to
> more than one place, for whatever unexpected reason that might come up.
>
> NB> I suppose at some point in the future the bugs server might change its
> NB> behaviour. So one could argue that everything is already documented
> NB> with this line in the bts man page:
>
> NB> "For full details about the commands, see the BTS documentation.
> NB> <https://www.debian.org/Bugs/server-control>"
>
> NB> I don't see any particular reason to single out the forwarded command
> NB> for extra documentation.
>
>

[toc] | [prev] | [next] | [standalone]

#701812

>>>>> "NB" == Nicholas Bamber <nicholas@periapt.co.uk> writes:

NB> I don't think that quite follows. I was not suggesting that
NB> bugs.debian.org change anything. But they might lock it down in the
NB> future. So if we document precisely how things work now we would be
NB> overdocumenting the system.

Well I'm just hoping something could be documented somewhere...

[toc] | [prev] | [next] | [standalone]

#702420

By the way one might be surprised that there could be two of these

$ w3m -dump http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718840 | grep Found
Found in versions apt-show-versions/0.22.1, apt-show-versions/0.22.7

based on

       found bug [version]
           Indicate that a bug was found to exist in a particular package
           version.  Without version, the list of fixed versions is cleared
           and the bug is reopened.

but only one of forwarded, based on

       forwarded bug address
           Mark the bug as forwarded to the given address (usually an email
           address or a URL for an upstream bug tracker).


which almost looks the same there on the bts man page...

[toc] | [prev] | [next] | [standalone]

#702786

On Mon, Dec 21, 2015 at 12:54:40AM +0800, 積丹尼 Dan Jacobson wrote:
> By the way one might be surprised that there could be two of these
> 
> $ w3m -dump http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718840 | grep Found
> Found in versions apt-show-versions/0.22.1, apt-show-versions/0.22.7
> 
> based on
> 
>        found bug [version]
>            Indicate that a bug was found to exist in a particular package
>            version.  Without version, the list of fixed versions is cleared
>            and the bug is reopened.

It's useful to denote that a bug is still present (or possibly
reintroduced) in a newer version of a package.  This is what allowing
aggregation of "found" versions provides.

> but only one of forwarded, based on
> 
>        forwarded bug address
>            Mark the bug as forwarded to the given address (usually an email
>            address or a URL for an upstream bug tracker).

The point of the forwarded command is either to simply indicate it has
been forwarded to someone, or to reference a URL where the discussion of
the issue upstream can be tracked.  If there isn't a canonical URL that
can be referenced, then the discussion may be to scattered to usefully
be tracked by that field.

That being said, it has already been shown the "address" part of the
command can be arbitrary text, so you can already do what was requested.

This still looks like a solution lacking a problem.  I asked before if
there was a specific case where knowledge of how to mark something as
forwarded to multiple URLs would have been useful, so I could better
understand your request, but got no response to that part of my email.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan@debian.org>

[toc] | [prev] | [next] | [standalone]

#702787

I am just saying that via a mechanical reading of the documents, one
cannot tell which items only allow / should have one vs. more arguments.
I just wish the docs would say how many.

JM> That being said, it has already been shown the "address" part of the
JM> command can be arbitrary text, so you can already do what was requested.

Yes I think getting away with putting a space between two URLs isn't
good. It would be better if the docs said that this is only meant for
one URL.

JM> This still looks like a solution lacking a problem.  I asked before if
JM> there was a specific case where knowledge of how to mark something as
JM> forwarded to multiple URLs would have been useful, so I could better
JM> understand your request, but got no response to that part of my email.

Sure, some problem might be part Redhat's fault, and part Kernel Team's
fault. You never know. Maybe 60/40. Maybe 50/50. So far they have all
been 100/0 or 0/100 but you never know and I just wish the docs would
say how many arguments are meant.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web