Bug#483179: reopen 483179, PTS: please do *not* link to Ubuntu Launchpad bugs page
On Fri, 13 Jun 2008, Ana Guerrero wrote:
retitle 483179 PTS: please *do not* link to Ubuntu Launchpad bugs page
09:41 <buxy> ana: and accept my decision as PTS maintainer
About buxy's second sentence, it is not at all a way to "finish" a discussion.
Accept my disagreement (and other's disgreement) as Debian Developers.
Well, independently of this quite hot topic I think you finally have to
accept the decision of the author of a piece of software (except you are
a customer and are paying to insert or remove a special feature). So I'm
afraid buxy is de facto right here.
I do care about what happens in whatever part of Debian on my packages, but
not at what happens in derivated distros. If somebody for $ANY derivative
distro find a bug that affects to Debian, this person should report in the
BTS or notify to Debian maintainers, whatever that works fine for both parts.
If reality shows that people refuse to do this - and BTW, Ububtu does not seem
to actually encourage its users to report bugs also to Debian - and thus I
think that a hint for the maintainer in the BTS is not really harmfull. So
accepting this decision seems not to be very hard.
Then you are only considering one Debian derivative when Debian has
thousands, and we can not track all of them and not all of them have a easy
tracking system, but there are some big ones besides Ubuntu that could be
considered as well.
So you rather want to retitle the bug to
Please link to <derivative-xy> BTS
and perhaps fork the bug report to mention every single derivative that
maintains a BTS which gives us a reasonable means to link to it.
Call it Debian Ecosystem Packaging Tracking System or something like that.
Sonds like an alternative if we find at least three reasonable link targets.
Heck! it could even track another distros, not only derivatives and being a
first step for sharing patches across distributions, idea that is around without
Very good idea. But for the concrete topic I think we should not stop
the pragmatic *existing* part of the solution until we might have a better