Re: Maintaining all of the testing-cabal packages under the OpenStack team
On 6/29/20 8:34 AM, Ondrej Novy wrote:
> 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.
You're mixing 2 things: working on OpenStack package, and caring not to
break them. I'm just asking for the later.
On 6/29/20 8:34 AM, Ondrej Novy wrote:
> yep, that's how it works. We need to move forward and don't keep old,
> buggy and unmaintained packages in Debian, right?
If I'm getting this right, not only you break things (which is ok, if it
isn't on purpose), but now claim that this is the right thing to do. No,
this is not how Debian works, it never was, and hopefully, never will.
> 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 agree this is best practice when backports are to be expected.
Cheers,
Thomas Goirand (zigo)
Reply to: