Hi, ne 28. 6. 2020 v 16:48 odesílatel Thomas Goirand <z...@debian.org> napsal:
> Hi, > > Under a single Github account, the below packages are maintained: > - mock > - subunit > - testtools > - fixtures > - funcsigs (deprecated, py2 backport) > - testresources > - traceback2 > - testscenarios > - testrepository > - extras > - linecache2 > > Currently, these packages are maintained by a variety of DDs, and > there's no uniform maintenance of them. > which is perfectly fine, that's how Debian works. The last upload of mock 4.0.2, by Ondrej, broke *a least*: > - nova (see: #963339) > - cloudkitty (see: #963069) > - congress (see: #963312) > - rally (see: #963381) > > All of the 4 packages above were able to build in Bullseye (ie: mock > 3.0.5) and FTBFS in Sid (with mock 4.0.2). > > Well done! :( > yep, that's how it works. We need to move forward and don't keep old, buggy and unmaintained packages in Debian, right? You should add autopkgtest to prevent this. Failed autopkgtest will block migration. Or we should start using full transitions, which is a bad idea imho. Ondrej, you once cared for the OpenStack packages. Why are you now > completely careless? > because it's really hard to cooperate with you. I already tried to explain it to you but you didn't listen. > More over, mock debhelper was upgraded to 13, for no apparent reason > (yet another "cosmetic fix" that isn't helping?). I'd like to remind > everyone that, increasing debhelper compat version to a number that > isn't in stable, without a specific reason (like the need of a specific > feature that wasn't there before) is just annoying for anyone > maintaining backports. That's truth even for when debhelper itself is > backported to oldstable (it's always nicer to be able to build a > backport without requiring another backport at build time). > nope, this is not true. Using the newest debhelper compat level is recommended, see man page. There is no reason to __not__ upgrade debhelper compat level. I will always upgrade debhelper in my packages to the newest debhelper as soon as possible. Please newer downgrade debhelper in my packages again without asking. I don't want this to happen again. So I am hereby asking to take over > the maintenance of these packages which aren't in the OpenStack team. > They will be updated regularly, each 6 months, with the rest of > OpenStack, following the upstream global-requirement pace. I'm confident > it's going to work well for me and the OpenStack team, but as well for > the rest of Debian. > for my packages (i'm uploader): no, sorry. Reasons: 1. I hate openstack-pkg-tools 2. I like pybuild 3. you hate pybuild and don't want to use it -- Best regards Ondřej Nový
