Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12690 > unrolled thread

Re: Maintaining all of the testing-cabal packages under the OpenStack team

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Maintaining all of the testing-cabal packages under the OpenStack team Ondrej Novy <novy@ondrej.org> - 2020-06-29 09:00 +0200
    Re: Maintaining all of the testing-cabal packages under the OpenStack team Scott Kitterman <debian@kitterman.com> - 2020-06-29 13:00 +0200
      Re: Maintaining all of the testing-cabal packages under the OpenStack  team Scott Talbert <swt@techie.net> - 2020-06-29 16:20 +0200
        Re: Maintaining all of the testing-cabal packages under the OpenStack team Scott Kitterman <debian@kitterman.com> - 2020-06-29 16:40 +0200
          Re: Maintaining all of the testing-cabal packages under the OpenStack  team Jean-Philippe MENGUAL <jpmengual@debian.org> - 2020-08-12 19:00 +0200
      Re: Maintaining all of the testing-cabal packages under the OpenStack team Scott Kitterman <debian@kitterman.com> - 2020-06-29 16:50 +0200
    Re: pybuild vs os-pkg-tools [was: Maintaining all of the  testing-cabal packages under the OpenStack team] Ondrej Novy <novy@ondrej.org> - 2020-07-07 08:40 +0200
      Re: pybuild vs os-pkg-tools [was: Maintaining all of the  testing-cabal packages under the OpenStack team] Ondrej Novy <novy@ondrej.org> - 2020-07-08 13:10 +0200

#12690 — Re: Maintaining all of the testing-cabal packages under the OpenStack team

[Multipart message — attachments visible in raw view] — view raw

Hi,

ne 28. 6. 2020 v 16:48 odesílatel Thomas Goirand <zigo@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ý

[toc] | [next] | [standalone]

#12691

On June 29, 2020 10:12:49 AM UTC, Thomas Goirand <zigo@debian.org> wrote:
>On 6/29/20 8:34 AM, Ondrej Novy wrote:
...
>>     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.

I'm substantially less enthusiastic about bumping compat levels than Ondrej, but since debhelper 13 is available in buster-backports, backporting is unrelated to whether it's a good idea or not.

Scott K

[toc] | [prev] | [next] | [standalone]

#12695 — Re: Maintaining all of the testing-cabal packages under the OpenStack team

On Mon, 29 Jun 2020, Scott Kitterman wrote:

>>>     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.
>
> I'm substantially less enthusiastic about bumping compat levels than 
> Ondrej, but since debhelper 13 is available in buster-backports, 
> backporting is unrelated to whether it's a good idea or not.

Can you elaborate on other reasons not the upgrade the compat levels?

Scott

[toc] | [prev] | [next] | [standalone]

#12696

[Multipart message — attachments visible in raw view] — view raw

On Monday, June 29, 2020 10:17:57 AM EDT Scott Talbert wrote:
> On Mon, 29 Jun 2020, Scott Kitterman wrote:
> >>>     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.
> > 
> > I'm substantially less enthusiastic about bumping compat levels than
> > Ondrej, but since debhelper 13 is available in buster-backports,
> > backporting is unrelated to whether it's a good idea or not.
> 
> Can you elaborate on other reasons not the upgrade the compat levels?
> 
> Scott

This is a matter of personal preference, but since the behavior of debhelper 
changes between compat versions, I prefer no to change it unless I have time 
to thoroughly QA changes in the package.  This generally means I don't change 
it often.

Unless there are issues with a specific compat level (hello compat 11) or the 
compat level has been deprecated, I tend to not to do it, but I'm generally 
pretty minimalist in my package updates.  That doesn't mean someone else is 
wrong to do so if they've checked that package is correct after the change.

Scott K

[toc] | [prev] | [next] | [standalone]

#12819 — Re: Maintaining all of the testing-cabal packages under the OpenStack team

Hi,
Interesting discussion folks, thanks. We're a little concerned that some 
of the messages may be perceived as not very respectful. You know, and 
probably are yourself affected, how it is hard to find new contributions 
in Debian and how it is important to have welcoming messages for new 
contributors, who start discovering a team through archives of the 
mailing list.

Please try to moderate your tone and not be too argumentative - maybe 
ask people to explain their ideas more if they don't seem to fit with 
your own? The question form is a good way to express some 
misunderstanding or enable someone to explicit one's point of view.

An interesting practice might be not to reply to mails imediately after 
reading if angry. Sending a less emotional mail can be more suitable to 
maintain a high quality of the technical debate.

Best regards

For the community team

-- 
Jean-Philippe MENGUAL
Debian Developer non uploading
Community team member
Accessibility team member
debian-l10n-french team member
President of Debian France non-profit organization

[toc] | [prev] | [next] | [standalone]

#12697

[Multipart message — attachments visible in raw view] — view raw

On Monday, June 29, 2020 7:53:46 AM EDT Thomas Goirand wrote:
> On 6/29/20 12:58 PM, Scott Kitterman wrote:
> > On June 29, 2020 10:12:49 AM UTC, Thomas Goirand <zigo@debian.org> wrote:
> >> On 6/29/20 8:34 AM, Ondrej Novy wrote:
> >>> 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.
> > 
> > I'm substantially less enthusiastic about bumping compat levels than
> > Ondrej, but since debhelper 13 is available in buster-backports,>
> > backporting is unrelated to whether it's a good idea or not.
> I'm not maintaining OpenStack through the official backports channel,
> because OpenStack users need to have access to all versions of OpenStack
> backported to the current Stable. These backports are available through
> a debian.net channel (available using extrepo).
> 
> Therefore, the debhelper backport is not available in my build
> environment unless I explicitly do some work to make this happen (and
> Ondrej is aware of that). Just bumping the debhelper version (and
> without a good reason to do so) just add some unnecessary work
> maintaining the debhelper backport for me. By all means, let's bump to
> version 12. But why version 13 if you don't need the added features?
> This makes no sense to me.

Since you are maintaining an external backports repository, I think it's 
perfectly reasonable to expect packages that would work with Debian Backports 
to be supported.  One debhelper upload per compat level doesn't seem like 
enough work to be worth all this complaining.

Scott K

[toc] | [prev] | [next] | [standalone]

#12729 — Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

[Multipart message — attachments visible in raw view] — view raw

Hi,

po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand <zigo@debian.org> napsal:

> This isn't about hating or loving pybuild. This is all about being able
> to control how this set of packages are build globally (the whole set of
> packages.


so you could wrap these global things around pybuild, right?

-- 
Best regards
 Ondřej Nový

[toc] | [prev] | [next] | [standalone]

#12733 — Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

[Multipart message — attachments visible in raw view] — view raw

Hi,

st 8. 7. 2020 v 12:14 odesílatel Thomas Goirand <zigo@debian.org> napsal:

> There would be no point doing that, as all what pybuild would be doing
> (ie: setup.py install and unit testing), I'd be overriding it.


it's doing much more, but nevermind.


> The other
> (IMO preferred) way would be to contribute to Pybuild to make it does
> what's needed for these packages, and in a way so that we can also make
> such global change for all OpenStack packages at once.
>

that's even better! Add support for stestr (or whatever is OS using now)
with correct autodetection and you are done.

-- 
Best regards
 Ondřej Nový

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web