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