[Reportbug-maint] Bug#862095: reportbug: Bugs in backported packages must not be sent to the BTS

[Neil Williams]

On Mon, 8 May 2017 16:29:06 +0200 (CEST)
Thorsten Glaser <t.glaser at tarent.de> wrote:

> On Mon, 8 May 2017, Adrian Bunk wrote:
> 
> > Doing that per-package would be the worst possible option,
> > there should be one place (mailing list or BTS query) for
> > getting all bugs.  
> 
> Absolutely not! It’s fully reasonable to track all bugs,
> backported or not, in the BTS.
> 
> The reason this policy exists in the first place is that
> historically, bpo was not part of Debian, backporters were
> not maintainers, and maintainers did not want to get spammed
> by problems from broken backports.
> 
> > >...
> > > 4. Due to the above, I believe a short-circuit/knee-jerk reaction
> > >    to force reportbug to deliver _all_ bpo bugreports to the bpo
> > >    mailing list is wrong, and this should at the least be tagged
> > >    with stretch-ignore and discussed more broadly.  
> > 
> > What you call "short-circuit/knee-jerk reaction" is the official
> > policy:  
> 
> You nicely cut off the quote from me at the wrong point.
> 
> I wrote that, by adding the Bugs: header to debian/control,
> reportbug happily forwards bugs to the mailing list instead
> of the BTS, and as such it’s the responsibility of each
> backporter (and/or user) to do that, NOT of the tool.

The existing support in reportbug would seem sufficient, albeit that is
seems under-utilised.

In general, I see no reason for bugs in backported versions to be
automatically hidden from the maintainers - if it is desired, it should
be an opt-out, just as it is currently.

Policy reflects reality and can change, it doesn't have to be a stick to
hit those who are being reasonable in their expectations and workload.

FWIW I would never add such a field to debian/control for packages
which I backport and maintain. Personally, I think such division is
only of historical interest, dating from the time when backports was
not in the main archive. I haven't seen a good use case for the
separation after that point.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reportbug-maint/attachments/20170508/e3bb8689/attachment-0001.sig>