In data sabato 30 settembre 2017 14:55:34 CEST, Adrian Bunk ha scritto: > On Sat, Sep 30, 2017 at 01:28:54PM +0200, Pino Toscano wrote: > > In data sabato 30 settembre 2017 13:17:43 CEST, Adrian Bunk ha scritto: > > > libgpod-nogtk-dev was a transitional package removed in libgpod 0.8.3-9. > > > > > > amarok is the only package build-depending on libgpod-nogtk-dev. > > > > Even if amarok is the only rdep, the "first I break, then I file > > serious bugs on rdeps" modus operandi is *not* a good way of > > cooperating with other packagers in Debian. > > Filing a bug some time before, or even writing an email, would have > > been a much nicer, and cooperative, way. > > amarok is not in testing and anyways needs a source upload for #784448.
This is because of the amarok status, although my note was for the general way to work in Debian. > It is also worth looking at the around 300 (sic) currently open RC bugs > I have reported for FTBFS that were *not* caused by me [1]: Sure, and that is completely not relevant with what I said, nor it can even be used as "excuse" to "dump and file". > Current status quo in Debian is that it is completely normal that > a new upload of some package is followed by me filing 10-50 RC bugs > against packages that FTBFS due to that change. No, it is not. You are mixing two things in the same pot: a) breakages due to side-effect (possibly not known in advance) of new versions of packages b) well-known breakages that some change is going to cause My note was a general remark that for things in the (b) category above a pre-emptive email/bug/etc to the interested rdeps *is* the optimal way to interface with other people. I do not care if other people just dump stuff in unstable and expect other to clean up after the mess they created -- it is simply *not* correct, not even fair. > So when the only rdep is one package that is not in testing and anyways > requires a (non-trivial) sourceful upload for re-entering testing, > I fail to see any reasonable justification for me to spend additional > time on going through any process longer than just filing an RC bug. And this is again this very specific case. -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
