In data sabato 30 settembre 2017 16:12:19 CEST, Adrian Bunk ha scritto: > On Sat, Sep 30, 2017 at 02:04:58PM +0200, Pino Toscano wrote: > > In data sabato 30 settembre 2017 14:55:34 CEST, Adrian Bunk ha scritto: > >... > > > 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 > >... > > In the vast majority of the RC bugs I report, the sole difference > between a) and b) is whether the uploader bothered to check whether > the new package might break rdeps.
Which you knew, yet ignored. > gtk-doc-tools 1.26 or Qt 5.9 likely breaking some rdeps is something > that is known in advance. Usually the breakages due to a new version of Qt tend to be very low. > > 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. > > #872796 #873023 #873444 #872742 #873020 #874187 > > Do you consider it fair that I had to submit bugs to help clean up the > mess created by the Qt maintainers dumping 5.9 into unstable without > first checking that all their rdeps still build? a) #872742 was detected during the transition, and was correctly fixed as part of it (thanks for reporting it) b) #874187 has nothing to do with Qt, but with the switch to GCC 7 c) Qt 5.9 was not "dumped" into unstable: it was tested with a large DE (Plasma), and a number of other packages; sure, there were 5 FTBFSes, and this is what I said earlier with "possibly not known in advance [side effects]" d) I don't see anybody forcing you to file bugs to "clean up a mess" (that did not actually exist); if you didn't have the time/will/etc, you could have *contacted* the team (see what I already said about cooperation); using these bugs as excuse like "I break things, since you broke them" is not exactly a constructive modus operandi, and just lead to a downhill path in lack of cooperation e) even said all the above: I don't see how this is relevant to the note I sent to you over what I saw regarding your libgpod upload; please do not change the topic like "... so what about the others?" > > > 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. > > I did this change as part of a QA upload also fixing one of these > FTBFS I reported but didn't cause (#876583). Sure, and I don't see how fixing that bug required dropping used (even if only in unstable) packages. Again, my note was only regarding the way a breakage was introduced in Debian, not on the upload as a whole. -- Pino Toscano
signature.asc
Description: This is a digitally signed message part.
