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

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.

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ý

Reply via email to