[gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

Hello

Looking to the list of packages still not supporting python 3.5:
https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt

and considering that we should even start testing python 3.6, I think it would
be nice if we could make portage to warn when PYTHON_COMPAT value is not
updated. It's really frustrating to still see new ebuilds being added with
obsolete values for PYTHON_COMPAT and relying on a few people looking to update
this. This is also causing huge delays to migrate to newer python versions and I
think it's responsibility of the maintainer to ensure his/her package is
supported on newer versions or, at least, have a bug and ping upstream for the
cases they need further fixing.

Of course, this wouldn't be a fatal check preventing you from committing a
package with outdated PYTHON_COMPAT, it would be a warning to remind you to
update it as soon as possible.

Any issues on trying to go further into implementing this warning? 

Thanks a lot

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 494 bytes --]

On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> Any issues on trying to go further into implementing this warning? 

Not an issue per se, but it should be pointed out that python 3.5 only
has a testing visibility, so this at the very least requires maintainers
to potentially have a separate testing chroot/VM to test when adding the
compat.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> > Any issues on trying to go further into implementing this warning? 
> 
> Not an issue per se, but it should be pointed out that python 3.5 only
> has a testing visibility, so this at the very least requires maintainers
> to potentially have a separate testing chroot/VM to test when adding the
> compat.
> 

Yes, but it's similar as the cases when we need to fix our packages to work with
a newer library they depend on. In this case it would be even easier as we can
have multiple python versions and switch to the newer one for testing while
going back to the stable one (if preferred) later.

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On Mon, 10 Jul 2017 13:43:43 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> Yes, but it's similar as the cases when we need to fix our packages
> to work with a newer library they depend on. In this case it would be
> even easier as we can have multiple python versions and switch to the
> newer one for testing while going back to the stable one (if
> preferred) later.
> 

I'm starting to think we need a collection of QA scripts in a repo
somewhere, optimized for symlinking into /etc/portage/hooks/install/

And make it standard practice for:

- Gentoo Devs to have those scripts
- Tinderboxers' to have those scripts

That's going to be the only way we can get these warnings in ways
*developers* will see them, but: 

1. Won't needlessly clutter stable users systems
2. Won't produce loads of ebuild bumps that do waves of metadata
updates for things that don't affect end users.

Presently the only things *like* this require hard-coded QA logic into
portage itself, which, while useful, pulls us back to the whole problem
where it might affect users, and becomes tightly coupled to portage's
release cycle.

We could however make things simpler, and have a package that installs
these QA hacks into the hooks dir for us, and then it would be a matter
of simply installing them via opt-in.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 816 bytes --]

On 07/10/2017 03:35 PM, Kent Fredric wrote:
> On Mon, 10 Jul 2017 13:43:43 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
>> Yes, but it's similar as the cases when we need to fix our packages
>> to work with a newer library they depend on. In this case it would be
>> even easier as we can have multiple python versions and switch to the
>> newer one for testing while going back to the stable one (if
>> preferred) later.
>>
> 
> I'm starting to think we need a collection of QA scripts in a repo
> somewhere, optimized for symlinking into /etc/portage/hooks/install/
> 

I might've read things too quickly, we're not talking a repoman check here?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On Mon, 10 Jul 2017 15:41:04 +0200
Kristian Fiskerstrand <k_f@gentoo.org> wrote:

> On 07/10/2017 03:35 PM, Kent Fredric wrote:
> > On Mon, 10 Jul 2017 13:43:43 +0200
> > Pacho Ramos <pacho@gentoo.org> wrote:
> >   
> >> Yes, but it's similar as the cases when we need to fix our packages
> >> to work with a newer library they depend on. In this case it would
> >> be even easier as we can have multiple python versions and switch
> >> to the newer one for testing while going back to the stable one (if
> >> preferred) later.
> >>  
> > 
> > I'm starting to think we need a collection of QA scripts in a repo
> > somewhere, optimized for symlinking into /etc/portage/hooks/install/
> >   
> 
> I might've read things too quickly, we're not talking a repoman check
> here?
> 

Yes, the warning would be a repoman check for version bumps, etc...

What he is talking about, is OT, and I want to automate with a buildbot
instance that can do automated testing for all python pkgs (to start
with) that have tests enabled in the ebuild.  I am also planning to
help with automatic version bumps for those pkgs as well.  If not
committed straight to the tree, then emailed as a patch to the
maintainers, perhaps in a pending repo/branch, bugzilla... TBD.


Oh, and I want to connect as many arch specific workers to it as well.

That should ease ebuild bumps, PYTHON_COMPAT and keywording
maintainence.

Once in place and operational, it should give the groundwork to add
other pkg types, not just python based pkgs.
-- 
Brian Dolbec <dolsen>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

[gentoo-dev] Re: About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Michael Palimaka]

On 07/10/2017 11:35 PM, Kent Fredric wrote:
> On Mon, 10 Jul 2017 13:43:43 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
>> Yes, but it's similar as the cases when we need to fix our packages
>> to work with a newer library they depend on. In this case it would be
>> even easier as we can have multiple python versions and switch to the
>> newer one for testing while going back to the stable one (if
>> preferred) later.
>>
> 
> I'm starting to think we need a collection of QA scripts in a repo
> somewhere, optimized for symlinking into /etc/portage/hooks/install/
> 
> And make it standard practice for:
> 
> - Gentoo Devs to have those scripts
> - Tinderboxers' to have those scripts
> 
> That's going to be the only way we can get these warnings in ways
> *developers* will see them, but: 
> 
> 1. Won't needlessly clutter stable users systems
> 2. Won't produce loads of ebuild bumps that do waves of metadata
> updates for things that don't affect end users.
> 
> Presently the only things *like* this require hard-coded QA logic into
> portage itself, which, while useful, pulls us back to the whole problem
> where it might affect users, and becomes tightly coupled to portage's
> release cycle.
> 
> We could however make things simpler, and have a package that installs
> these QA hacks into the hooks dir for us, and then it would be a matter
> of simply installing them via opt-in
In addition to the checks that are bundled, Portage already natively
supports custom post-install QA checks in:

* /usr/local/lib/install-qa-check.d
* /usr/lib/install-qa-check.d
* $REPO/metadata/install-qa-check.d

It's just a matter of someone writing and shipping them. I've been very
slowly preparing a collection based on the common type of tinderboxing
bugs that are filed and porting parts of lintian, but I haven't finished
yet.

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 857 bytes --]

On 10/07/17 12:43, Pacho Ramos wrote:
> El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
>> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
>>> Any issues on trying to go further into implementing this warning? 
>> Not an issue per se, but it should be pointed out that python 3.5 only
>> has a testing visibility, so this at the very least requires maintainers
>> to potentially have a separate testing chroot/VM to test when adding the
>> compat.
>>
> Yes, but it's similar as the cases when we need to fix our packages to work with
> a newer library they depend on. In this case it would be even easier as we can
> have multiple python versions and switch to the newer one for testing while
> going back to the stable one (if preferred) later.
>
Is this something that could be aided any by the tinderbox'ing project?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 874 bytes --]

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Rich Freeman]

On Mon, Jul 10, 2017 at 7:04 AM, Pacho Ramos <pacho@gentoo.org> wrote:
>
> Looking to the list of packages still not supporting python 3.5:
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
>

I realize a warning will address most of the issue, but when creating
lists like these it can be helpful to stick the maintainer names on
it, so that maintainers can just search for their name on the wall of
shame.  :)

>
> Any issues on trying to go further into implementing this warning?
>

I think warnings in repoman are a great idea.  If somebody maintains a
package that uses python but isn't seriously into python otherwise
they probably won't notice when new versions are available to be
tested/etc.  The only thing I would suggest is that the warning not be
triggered until the python team thinks the new version is ready for
testing/etc.  I'm not sure if they introduce masked versions into the
tree before things settle down or not.  If not then this is moot.

-- 
Rich

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> Hello
> 
> Looking to the list of packages still not supporting python 3.5:
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> 
> and considering that we should even start testing python 3.6, I think it would
> be nice if we could make portage to warn when PYTHON_COMPAT value is not
> updated. It's really frustrating to still see new ebuilds being added with
> obsolete values for PYTHON_COMPAT and relying on a few people looking to update
> this. This is also causing huge delays to migrate to newer python versions and I
> think it's responsibility of the maintainer to ensure his/her package is
> supported on newer versions or, at least, have a bug and ping upstream for the
> cases they need further fixing.
> 
> Of course, this wouldn't be a fatal check preventing you from committing a
> package with outdated PYTHON_COMPAT, it would be a warning to remind you to
> update it as soon as possible.
> 
> Any issues on trying to go further into implementing this warning? 

What about the situation where a package is not compatible with newer
versions of python so does not need a PYTHON_COMPAT change?

I don't think you can assume PYTHON_COMPAT is outdated for a package
just because it doesn't have the latest versions of python
listed. The only time you can know for sure that it is outdated is if it
lists a version of python that no longer exists in the tree.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Alexis Ballier]

On Mon, 10 Jul 2017 11:55:30 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> > Hello
> > 
> > Looking to the list of packages still not supporting python 3.5:
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> > 
> > and considering that we should even start testing python 3.6, I
> > think it would be nice if we could make portage to warn when
> > PYTHON_COMPAT value is not updated. It's really frustrating to
> > still see new ebuilds being added with obsolete values for
> > PYTHON_COMPAT and relying on a few people looking to update this.
> > This is also causing huge delays to migrate to newer python
> > versions and I think it's responsibility of the maintainer to
> > ensure his/her package is supported on newer versions or, at least,
> > have a bug and ping upstream for the cases they need further fixing.
> > 
> > Of course, this wouldn't be a fatal check preventing you from
> > committing a package with outdated PYTHON_COMPAT, it would be a
> > warning to remind you to update it as soon as possible.
> > 
> > Any issues on trying to go further into implementing this
> > warning?   
> 
> What about the situation where a package is not compatible with newer
> versions of python so does not need a PYTHON_COMPAT change?
> 
> I don't think you can assume PYTHON_COMPAT is outdated for a package
> just because it doesn't have the latest versions of python
> listed. The only time you can know for sure that it is outdated is if
> it lists a version of python that no longer exists in the tree.

Maybe we should add some - modifier to PYTHON_COMPAT, just like
keywords, indicating it has been tested to *not* work.
PYTHON_COMPAT=( python{2_7,3_4,3_5} -python_3_6 )

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Pacho Ramos]

El lun, 10-07-2017 a las 11:55 -0500, William Hubbs escribió:
> On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> > Hello
> > 
> > Looking to the list of packages still not supporting python 3.5:
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> > 
> > and considering that we should even start testing python 3.6, I think it
> > would
> > be nice if we could make portage to warn when PYTHON_COMPAT value is not
> > updated. It's really frustrating to still see new ebuilds being added with
> > obsolete values for PYTHON_COMPAT and relying on a few people looking to
> > update
> > this. This is also causing huge delays to migrate to newer python versions
> > and I
> > think it's responsibility of the maintainer to ensure his/her package is
> > supported on newer versions or, at least, have a bug and ping upstream for
> > the
> > cases they need further fixing.
> > 
> > Of course, this wouldn't be a fatal check preventing you from committing a
> > package with outdated PYTHON_COMPAT, it would be a warning to remind you to
> > update it as soon as possible.
> > 
> > Any issues on trying to go further into implementing this warning? 
> 
> What about the situation where a package is not compatible with newer
> versions of python so does not need a PYTHON_COMPAT change?
> 
> I don't think you can assume PYTHON_COMPAT is outdated for a package
> just because it doesn't have the latest versions of python
> listed. The only time you can know for sure that it is outdated is if it
> lists a version of python that no longer exists in the tree.
> 
> William
> 

Maybe we could handle it like other warnings: ignore it but ensure we have a bug
report to track the issue (I have seen cases of a comment being added showing
that a package wasn't ready for python 3.5 but no bug reference listed :/). 

It looks to me like the same we do for parallel build warnings

Re: [gentoo-dev] About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Kent Fredric]

On 11 Jul 2017 01:41, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
>
> On 07/10/2017 03:35 PM, Kent Fredric wrote: 
> > On Mon, 10 Jul 2017 13:43:43 +0200 
> > Pacho Ramos <pacho@gentoo.org> wrote: 
> > 
> >> Yes, but it's similar as the cases when we need to fix our packages 
> >> to work with a newer library they depend on. In this case it would be 
> >> even easier as we can have multiple python versions and switch to the 
> >> newer one for testing while going back to the stable one (if 
> >> preferred) later. 
> >> 
> > 
> > I'm starting to think we need a collection of QA scripts in a repo 
> > somewhere, optimized for symlinking into /etc/portage/hooks/install/ 
> > 
>
> I might've read things too quickly, we're not talking a repoman check here? 

Not sure repoman is enough here.

But I'm just saying I see a growing number of problems that can only be detected by actually building the package, and can't be done with static analysis.

And then, some of those that can be addressed with repoman are annoying to solve with repoman, as you're tying your release cycle to repomans.

And what if your check needs external tools? Surely repoman would be a terrible place to put those dependencies
>
> -- 
> Kristian Fiskerstrand 
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net 
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 
>

--