On Wed, 06 Oct 2010, Sandro Tosi wrote: > On Wed, Oct 6, 2010 at 15:33, Stefano Zacchiroli <z...@debian.org> wrote: > > On Thu, Sep 30, 2010 at 07:01:29PM +0200, Sandro Tosi wrote: > >> >From a reportbug POV, it's not a big deal to redirect the reports for > >> bpo packages to something different than sub...@b.d.o. What I need to > >> know is: > >> > >> - the address where to send the bugs > >> - a regular expression (bonus points if already in python format) to > >> precisely identify bpo packages from the package version > >> - if we need to implement it (oh, did I mention that a patch would be > >> awesome?) :) > > > > No, you didn't, but I kinda guessed so :-) > > > > As we're in deep freeze now, it's time to take a decision on that and > > I'd say that it's essentially Don's call. If nothing happens, we can > > keep as a fallback solution that of using Send-To, to be eventually > > advertised in backport rules for Squeeze, setting the submit@ as an > > alias for the mailing list. > > Just a note that using Send-To requires to add a bug control file to > each upload to bpo which I consider a huge overkill solution to that.
Right. I'm sort of torn in two directions here about these bugs. What would be very nice is to have some method of determining from where a package was installed (that is, which Release file to look at to find out where the package came from) and then allow for Send-To to be set in the Release file on a mirror. But I can't think of any way to make that happen. That leaves us with either Client Side: 1) implementing hacks by looking for bpo in the versions 2) polling rmadison(?) to find out if it's bpo. BTS Side 1) handling everything in the BTS. I'm coming around to the idea that unless it's possible to determine from which archive a package was installed[1] we'll have to do this all in the BTS, because it's the only thing that we can control completely, and make changes to later if we change our minds. Don Armstrong 1: There are a couple of other reasons this would be useful, including debugging installs, etc. but I'm not sure it's worth the space or implementation. -- To punish me for my contempt of authority, Fate has made me an authority myself -- Albert Einstein http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006182053.gh3...@rzlab.ucr.edu