Python2 removal: package with low-popcon reverse dependencies
Hi, python-cachetools provides modules for Python2 and Python3. The Python2 module as two reverse dependencies, both with low installed popcon: python-cachetools: 302 mopidy-podcast: 109 mopidy-internetarchive: 95 This would nevertheless be a case for the "py2keep", right? Would this also be the case if python-cachetools itself had a lower popcon, say 50? Or is any form of dependency a case for "py2keep"? Furthermore, the instructions in the Python2 removal request #937627 say: > Also any dependencies on an unversioned python package (python, > python-dev) must not be used, same with the python shebang. These > have to be replaced by python2/python2.7 dependencies and shebang. The binary package has versioned dependencies generating during the build process, so there is nothing else to do, right? Christian
Re: Python2 removal: package with low-popcon reverse dependencies
On 11.10.19 19:47, Matthias Klose wrote: > On 11.10.19 18:27, Christian Kastner wrote: >> This would nevertheless be a case for the "py2keep", right? > > No. > > #933348 is another bug for removed packages (mopidy-scrobler). Do you > really want to keep that? Not at all, I'd actually prefer just dropping the Python2 version of python-cachetools. However, this breaks things, and it wasn't entirely clear to me much breakage is acceptable. > Is the mopidy popcon really enough to keep it? Don't look at the > popcon of any python module. The relevant popocon is the one for the > application. OK. > No, this is not yet done. Pending a dh-python upload. So assuming I had a Python2 module that needed updating (instead of outright removing it), I'd await this upload. Thanks, Christian
Re: Python2 removal: package with low-popcon reverse dependencies
On 11.10.19 18:27, Christian Kastner wrote: Hi, python-cachetools provides modules for Python2 and Python3. The Python2 module as two reverse dependencies, both with low installed popcon: python-cachetools: 302 mopidy-podcast: 109 mopidy-internetarchive: 95 This would nevertheless be a case for the "py2keep", right? No. #933348 is another bug for removed packages (mopidy-scrobler). Do you really want to keep that? Is the mopidy popcon really enough to keep it? Don't look at the popcon of any python module. The relevant popocon is the one for the application. Would this also be the case if python-cachetools itself had a lower popcon, say 50? Or is any form of dependency a case for "py2keep"? Furthermore, the instructions in the Python2 removal request #937627 say: Also any dependencies on an unversioned python package (python, python-dev) must not be used, same with the python shebang. These have to be replaced by python2/python2.7 dependencies and shebang. The binary package has versioned dependencies generating during the build process, so there is nothing else to do, right? No, this is not yet done. Pending a dh-python upload.
Re: Streamlining the use of Salsa CI on team packages
On 19-09-15 20 h 31, Louis-Philippe Véronneau wrote:
> On 19-09-05 01 h 40, Louis-Philippe Véronneau wrote:
>> Hello folks!
>>
>> I'd like to propose we start using Salsa CI for all the team packages. I
>> think using a good CI for all our packages will help us find packaging
>> bugs and fix errors before uploads :)
>>
>> I also think that when possible, we should be using the same CI jobs for
>> our packages. The Salsa CI Team's default pipeline [1] is a good common
>> ground, as currently it:
>>
>> * builds the package
>> * runs piuparts
>> * runs autopkgtest
>> * runs lintian
>> * runs reprotest
>> * and does more!
>>
>> I don't think a failing CI should be a blocker for an upload, but I
>> think it's a good red flag and should be taken in account.
>>
>> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
>> debian/gitlab-ci.yml [2]. I guess we should also do the same.
>>
>> Thoughts? If we decide to go ahead with this, I guess we should modify
>> the policy accordingly and contact the Salsa Team to see if adding this
>> additional load is OK with them.
>>
>> [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
>> [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245
> These are the steps I see going forward with this:
>
> --
> 1. Agree on a default pipeline we should be using on the DPMT & PAPT
> packages.
>
> 2. Draft a proposed modification to the DPMT and the PAPT policies
>
> 3. Adopt that proposed modification once we reach consensus
>
> 4. Wait for the "All Clear" from the Salsa Team
>
> 5. Commit the previously agreed upon CI pipeline to all the DPMT & PAPT
> packages, while making sure the CI isn't ran on that push ("-o ci.skip")
> --
>
> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
> the most mature solution, has more contributors and has more features
> (including reprotest and piuparts). This option seems to have had the
> most support so far.
>
> Hans-Christoph Steiner proposed we use "ci-image-git-buidpackage"
> instead [2]. The code behind it is simpler and the way it's built makes
> it possible for maintainers to modify the CI for their packages.
>
> For step 2, so far people seemed to agree that:
>
> * having a standardised CI pipeline is a good idea
> * the CI should be used as a tool to help us improve our packages, and
> not be required to pass
>
> Please contribute to this discussion if you care about this issue! I'll
> try to draft something more concrete in the next few days.
>
> [1] https://salsa.debian.org/salsa-ci-team/pipeline
> [2] https://salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage
>
As promised, here's a draft proposal on CI usage for the team:
https://salsa.debian.org/python-team/tools/python-modules/merge_requests/12/
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
⠈⠳⣄
signature.asc
Description: OpenPGP digital signature
Re: What is the process to update the DPMT and PAPT policies?
On 19-09-16 08 h 00, Ondrej Novy wrote: > Hi, > > po 16. 9. 2019 v 1:59 odesílatel Louis-Philippe Véronneau > napsal: > >> What is the process to update the DPMT and PAPT policies? > > > we don't have process/policy to update policy. > > So I will propose one and let's add this process to policy itself: > >- anyone can submit merge request >- with MR created, send email to ML >- give seven? days grace period to discuss proposal >- to accept MR we needed at least one? ack from DPMT admins > > Comments? :) > This made a lot of sense to me, so I made an MR to implement this: https://salsa.debian.org/python-team/tools/python-modules/merge_requests/11 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
Merging the PAPT and the DPMT
On 19-09-16 08 h 00, Ondrej Novy wrote: > Hi, > > po 16. 9. 2019 v 9:55 odesílatel Mattia Rizzolo napsal: > >> I wonder, I think the historical reasons for papt and dpmt to be separated >> don't quite stand anymore. Perhaps the only difference left is the actual >> technical difference between an application and a module as described in >> the python policy (rather in the team one). >> > > I don't know historical reason but I agree we could/should merge DPMT and > PAPT policies together. > For those interested in having a look at it, I created a MR on Salsa [1] to try to merge the two policies into one. [1] https://salsa.debian.org/python-team/tools/python-modules/merge_requests/10 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ signature.asc Description: OpenPGP digital signature
