Re: Timing of Python upstream and Debian releases

[Thomas Goirand]

On 7/6/20 9:04 PM, Matthias Klose wrote:
> Starting with Python 3.8, Python upstream changed to a time based yearly 
> release
> schedule, targeting the first release of a major Python version (3.x) for
> October of each year.  For the transition to 3.8:
> 
>  - we add 3.8 as supported in November
>  - made 3.8 the default in March
>  - dropped 3.7 in April
> 
> That's a little bit late looking at the Debian release schedule, so a little
> speedup would be needed if we want to target the current Python release for 
> the
> current Debian release.  For 3.8 Ubuntu started to prepare the switch a bit
> earlier, using the results for a better experience in Debian:
> 
>  - added 3.8 in mid October
>  - made 3.8 the default in mid December
> 
> Technically it would be possible to do the defaults change before the Debian
> freeze, however there's usually a tail of follow-up upstream releases required
> to support a new major Python version, unless you opt for actively backporting
> changes in various packages.  Having the confidence, that the switch is 
> feasible
> in another distro certainly helps doing the transition in Debian, however it
> adds a delay.  I don't think it's feasible to do the transition in 
> experimental
> first, or doing a large test rebuild, because it requires keeping the whole
> python stack in sync with testing/unstable.
> 
> So what I'm proposing here is to aim to support 3.9 as early as possible as a
> supported Python3 version, starting with the 3.9 upstream release, and fixing
> stuff on the go.  Then decide in November, if we can do the defaults change to
> 3.9, or if we drop 3.9 again, or ship with two supported Python3 versions.

This looks reasonable, thanks for opening the discussion and doing the
hard work. However, I wouldn't be for shipping 2 supported versions, and
would prefer if we could have only one if possible, as otherwise this
means running unit tests at build time against 2 python versions, which
then takes twice as much build time: that's annoying and useless
(because at the end, only one of these versions will be in use).

Cheers,

Thomas Goirand (zigo)

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

[Thomas Goirand]

On 7/7/20 8:20 AM, Ondrej Novy wrote:
> Hi,
> 
> po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand  > 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?

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. 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.

I've been thinking about it for a while, but my ideas aren't clear
enough to start something (yet).

Cheers,

Thomas Goirand (zigo)

Re: Request to join Python Modules Team

[Ondrej Novy]

Hi,

so 4. 7. 2020 v 9:17 odesílatel Sao I Kuan  napsal:

> Ping o/ Or am I missing any necessary information?
>

I'm sorry, I overlooked your request. Added to team, welcome.

-- 
Best regards
 Ondřej Nový

Re: Request to join Python Modules Team

[Ondrej Novy]

Hi,

ne 5. 7. 2020 v 18:46 odesílatel Geert Stappers 
napsal:

> Whenever things get stalled it is good to ask:
>
>Who is waiting on who?
>

We have a rule between admins we are processing join request after few days
to give everyone chance to give their opinions.

In this particular case it was my fault and overlooked that email.

I volunteer to be part of "Some administrator".
>

cool. Current admins needs to agree, so: @piotr, @stefanor, @kitterman,
@bzed: your opinions please?

Debian tradition I will be re-introducing is sending "done messages".
>

no need to re-introduce, I'm always sending welcome message :)

-- 
Best regards
 Ondřej Nový

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

[Ondrej Novy]

Hi,

st 8. 7. 2020 v 12:14 odesílatel Thomas Goirand  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ý

Re: py2removal - make all leaf applications RC

[Sandro Tosi]

> I propose to raise the severity of all leaf applications in 3 days, if
> i dont hear any objections.

This is now enabled and at the next run (in ~50 minutes) it will take effect.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi