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: Stefano Rivera Newsgroups: linux.debian.maint.python Subject: Re: Enabling salsa-ci on all Debian Python Team repos Date: Fri, 23 Sep 2022 08:30:01 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Fri Sep 23 06:28:34 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-106.841 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, USER_IN_DKIM_WELCOMELIST=-0.01, USER_IN_DKIM_WHITELIST=-100] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 Mail-Followup-To: debian-python@lists.debian.org X-Gpg-Public-Key: http://www.rivera.za.net/stefano.gpg MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: NeoMutt/20201127 X-Mailing-List: archive/latest/20337 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20220923062812.vkmfwlf67fkj3qi7@satie.tumbleweed.org.za Approved: robomod@news.nic.it Lines: 30 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Fri, 23 Sep 2022 06:28:12 +0000 X-Original-Message-ID: <20220923062812.vkmfwlf67fkj3qi7@satie.tumbleweed.org.za> X-Original-References: <6f483545-27cb-0d05-d813-50c482284e6c@t-online.de> <794f0943-c833-0705-0f0d-88e90c0c41d4@t-online.de> Xref: csiph.com linux.debian.maint.python:14494 Hi Carsten (2022.09.23_05:01:05_+0000) > sure, that's a killer argument that I can't really argue against. But that > is not the point for me. > > For all these checks we already have existing infrastructure, running the > same also by a pipeline job isn't helping at all if it's not clear how to > handle the fallout (we already mostly have seen in other places too!). Yeah, it's similar for me. I test build locally, my sbuild setup does most (but not all) of the same checks as gitlab CI. Then when I'm happy I push and upload. If there is any gitlab CI, it runs too late. And if it fails, I usually don't even bother to investigate, because I trust my local setup implicitly. Anything that's failing in gitlab CI is almost certain to be a failure specific to gitlab CI. I do see a value in having it enabled globally, for the team, though. 1. It can make the team packages friendlier to new contributor team members who don't have a setup like that. I would like to see our team act more like a team and have people contribute to packages that they don't regularly maintain. 2. Getting a test failure on a merge-request catches contributor mistakes early. I love having CI on incoming patches like that. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272