Path: csiph.com!1.us.feeder.erje.net!3.us.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Sandro Tosi Newsgroups: linux.debian.maint.python Subject: Re: Enabling salsa-ci on all Debian Python Team repos Date: Tue, 20 Sep 2022 21:20:01 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Tue Sep 20 19:10:32 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.5 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-vs1-f45.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Gm-Message-State: ACrzQf1YfNhsSWEWwMqGlmRAtj3wwmVgOn9Fbj3AoSef0X75vawwygmC gAuN15gHjqCxN2qnRT7vO6t/poNjxMmCdHfAb5nqv7CU X-Google-SMTP-Source: AMsMyM7yw4EyITNvshFwyDzE9rH0Owci3JRv6XTp/J1qYiEIPqldE2IdCqKIoUQ0K6bDvfIAlz+gf8ix00TBdfINtjE= X-Received: by 2002:a67:a202:0:b0:39b:181d:bd20 with SMTP id l2-20020a67a202000000b0039b181dbd20mr3728776vse.51.1663701009832; Tue, 20 Sep 2022 12:10:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Mailing-List: archive/latest/20324 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAB4XWXy5z+3Zw4=-M5=YLF8_YP0f44PsvP3znnjDV40JdhAVmQ@mail.gmail.com Approved: robomod@news.nic.it Lines: 34 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Tue, 20 Sep 2022 15:09:43 -0400 X-Original-Message-ID: X-Original-References: <6f483545-27cb-0d05-d813-50c482284e6c@t-online.de> Xref: csiph.com linux.debian.maint.python:14482 > Am 20.09.22 um 16:13 schrieb Emanuele Rocca: > > Salsa CI is useful because it automatically performs binary/source builds, > > arm64 crossbuilds, and it runs various pretty important tests such as lintian, > > piuparts, reproducible build testing, and more. It also runs autopkgtest in > > LXC. > > quite most of these steps I usually need to do locally before I do any > upload of packages. So I see no real gain to run any pipeline by > default, for me this would be just burning energy in CPU cycles just for > "because we can". exactly this. the vast majority of the team members (based on the commits email i receive) are uploading the package to the archive at the same time as they are pushing a full set of changes to salsa (and sometimes only *after* the package has been ACCEPTED); in this case CI runs too late, and it has 0 benefit for that specific upload. For future ones? maybe, but that's to be proven, and the burden of proof is on the proponent. Someone with upload rights still need to verify (and build!) a package locally, so what would be the advantage of this CI for our packages, given only a very very tiny number of MRs are submitted i could see the benefit for projects that receive external contributions and/or are released out-of-sync with such contributions (say dh-python) but for /packages/, as Carsten said, it's a waste of CPU time to enable CI, IMO -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi