Re: Enabling salsa-ci on all Debian Python Team repos
Hi, On 2022-09-20 03:09, Sandro Tosi wrote: > 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. Very interesting, I was missing this piece of information. So first do all the work locally, perform all the testing manually, upload the package to ftp-master and *then* when you're finished push to Salsa? What's wrong with pushing your work before uploading to ftp-master instead? :-) If you're worried about breaking things, that's what git revert and/or branches are for. I can maybe imagine that one doesn't like frequent merge requests and merge commits, you can skip that too: just use a remote branch for testing and only push to master once happy. My workflow is roughly: - while not done: - few local commits, binary build, basic local testing - git push - see if the pipeline is green - source build, sign, upload To me this seems a better approach in terms of team collaboration too. While you iterate on your work it's clear to other team members that someone is on the package, which may help in terms of avoiding duplicated efforts.
Re: Enabling salsa-ci on all Debian Python Team repos
Hallo Carsten, On 2022-09-20 05:35, Carsten Schoenert wrote: > 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. Well but that's the whole point of automated testing. There's no *need* to do it locally if it's already done by Salsa for you. What is already automated and working pretty well is: - amd64 build - i386 build - source build - autopkgtest - blhc - lintian - piuparts - reprotest - arm64 crossbuild That's a pretty time consuming list of things to go through for a human! The only work left to be done on your machine is a binary build to see if the packages look good, perhaps some specific manual testing [1], source build and upload. Isn't that better? [1] though that may be an opportunity for writing a new autopkgtest!
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On Tue, Sep 20, 2022 at 08:31:14AM -0400, Sandro Tosi wrote: > the way i worded my initial question was so that you could list the > reasons that make it so useful, in detail: so would you like to do? 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. Sure you can do all this manually on your own, but it's better to live in a world where the machines work for us rather than the other way around. :-)
Re: Enabling salsa-ci on all Debian Python Team repos
Hi Sandro, On 19/09 02:14, Sandro Tosi wrote: > what would the team get out of doing this? The way I see it, CI on Salsa is so useful that it should be enabled by default unless there are good reasons not to. ciao, Emanuele
Enabling salsa-ci on all Debian Python Team repos
Hello debian-salsa-ci and debian-python! I was wondering if it would make sense to enable CI/CD on Salsa for all projects owned by the Debian Python Team, or if there's any concern about scaling issues in terms of pipeline workers (or anything else really). For the past few days I've been enabling CI/CD on Salsa for various packages owned by the DPT. I've been doing this on a case-by-case basis: if the package I wanted to work on (for reasons unrelated to CI) did not have CI/CD yet, I'd add [1] as the pipeline configuration file and carry on with my work. Perhaps there's an opportunity to automate and getting wider CI usage. Thanks, Emanuele [1] recipes/debian.yml@salsa-ci-team/pipeline
Bug#1019928: ITP: python-phx-class-registry -- module to define global factories and service registries
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python-phx-class-registry Version : 3.0.5 Upstream Author : Phoenix Zerin * URL : https://github.com/todofixthis/class-registry * License : MIT Programming Lang: Python Description : module to define global factories and service registries At the intersection of the Registry and Factory patterns lies the ClassRegistry. . This module allows to: . * Define global factories that generate new class instances based on configurable keys. * Seamlessly create powerful service registries. * Integrate with setuptools's entry_points system to make registries extensible by 3rd-party libraries. --- The module is a dependency of backblaze-b2 since 3.5.0: https://bugs.debian.org/1019925
Bug#1019745: RFP: sphinx-enum-tools -- expand Python's enum module in Sphinx documentation
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: sphinx-enum-tools Version : 0.9.0 Upstream Author : Dominic Davis-Foster * URL : https://github.com/domdfcoding/enum_tools * License : LGPL-3 Programming Lang: Python Description : expand Python's enum module in Sphinx documentation The enum_tools Sphinx extension can be used to document Enums better than autoclass can currently. Additionally, this library includes a decorator to add docstrings to Enum members from a comment at the end of the line. --- The package is being requested since the latest flask-limiter version uses the enum_tools extension for its documentation.
Joining the team
Hi! I'd like to join the debian-python team to help with general QA work on all packages. My salsa login is ema. I have read the policy [1] and accept it. [1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
