Path: csiph.com!eternal-september.org!feeder.eternal-september.org!aioe.org!bofh.it!news.nic.it!robomod From: Ole Streicher Newsgroups: linux.debian.maint.python Subject: Re: Numpy migration? Date: Sat, 05 Jan 2019 20:50:02 +0100 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Sat Jan 5 19:48:09 2019 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.999 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, HEADER_FROM_DIFFERENT_DOMAINS=0.001, LDO_WHITELIST=-5] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 X-Greylist: delayed 19821 seconds by postgrey-1.36 at bendel; Sat, 05 Jan 2019 19:30:33 UTC User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Lines: 68 X-Mailing-List: archive/latest/16658 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/87tvimq4vf.fsf@orrococo Approved: robomod@news.nic.it Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sat, 05 Jan 2019 20:30:28 +0100 X-Original-Message-ID: <87tvimq4vf.fsf@orrococo> X-Original-References: <87a7kfqk65.fsf@orrococo> <8736q7qh9w.fsf@orrococo> <20190105153545.GB26988@mapreri.org> Xref: csiph.com linux.debian.maint.python:11207 Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 04:02:35PM +0100, Ole Streicher wrote: >> I'll do tonight. It however looks a bit suboptimal: when the CI test >> with a new version fails for an old reverse dependency, then the new >> version obviously breaks that old package. So, the breakage could be >> detected (and taken into account) automatically. Why do we need a manual >> action then? > > Let me try to suggest you see from another side: the goal of the Breaks > field is to prevent a given combination of known broken packages to be > installed. > Currently autopkgtest blocks the migration of numpy, but if there wasn't > that block a Breaks should still be added, as the astropy in testing is > not compatible with the new numpy. The fact that it hints britney to > trigger the right tests is just a "side effects", the Breaks should be > added nonetheless, theoretically; in practice, we rarely did it before > autopkgtest started blocking the testing migration. I agree (with the explanation in your other mail) here; it just states the fact that they really don't go together very well (at least in situation similar to the specific CI test). >> Python-astropy is however going to be removed completely; it has >> however some cruft rdeps left in unstable. So, it cannot removed from >> unstable now, and therefore still remains in testing and >> (unnecessarily) blocks the numpy migration. Python-astropy already >> has an RC bug, but its autoremoval from testing is still not even >> announced yet. > > Maybe you could ask the release team to hasten the removal of > python-astropy and rdeps from testing? If the plan is to not relase > it in buster I don't see a reason to keep it further. Couldn't we just also add a "breaks" to numpy? The important fact here is, that the new numpy and the current python-astropy don't work together; and this is independent of whether a fixed python-astropy version exists. This would remove one dependent party (release team) from the chain of blocking causes for the migration. >> The migration blocking CI tests seem to cause much more headaches than >> just "fix your bugs"... > > Well, from what I see, it has helped a lot in this half a year detect a > ton of regressions that would have otherwise bothered several people in > a later moment… I usually regularly look into my packages and file bugs if a CI test fails caused by a buggy updated dependency. This works well without the need of blocks. It would also work, when a failing CI test would automatically trigger a bug report against the updated package, which then could be re-assigned to the rdep in case the problem was there. So, I value very much the CI tests by themself: they are the greatest invention since sliced bread, but I still dislike the inflexible handling of blocks. Often, a failing CI test makes a package only buggy with respect to a certain feature, so it would correspond to a "important" or "normal" bug severity. They are however always handled like a "serious" bug by preventing migration. I miss the "That was not a serious failure" button. Thanks fur your help! Best Ole