| *** elodilles is now known as elodilles_ooo | 05:45 | |
| opendevreview | Takashi Kajinami proposed openstack/releases master: Create a new release of yaql https://review.opendev.org/c/openstack/releases/+/951377 | 07:36 |
|---|---|---|
| opendevreview | Lajos Katona proposed openstack/releases master: Openstacksdk 4.6.0 https://review.opendev.org/c/openstack/releases/+/951388 | 09:39 |
| frickler | release-team: I prepared a sample 2023.2-eol tag replicating the metadata as I think the bot would have done this. please have a look before I push this to gerrit, I'll then repeat the same for the other kolla repos https://github.com/osfrickler/ansible-collection-kolla/releases/tag/2023.2-eol | 10:36 |
| frickler | (cc mnasiadka ^^) | 10:36 |
| sean-k-mooney | frickler: is there a good way to test https://review.opendev.org/c/openstack/project-config/+/951395? the best i can think of is to create a dnm to a non config repo whre i overried the defintion fo test-release-openstack to use noble i.e. emulate the change | 11:36 |
| sean-k-mooney | frickler: context is we are still usign focal on py 3.8 to test the packaging of our python projects | 11:36 |
| sean-k-mooney | but if we want to adopt the new way of expressing the license https://review.opendev.org/c/openstack/nova/+/951226 we need 3.9+ | 11:37 |
| sean-k-mooney | since we only uspprot 3.10+ offcially now it reaonsble to use 3.10 (or 3.9) in the test job to build the packages | 11:38 |
| sean-k-mooney | going ot noble will actuly use 3.12 not that i think of it but again that valid | 11:39 |
| frickler | sean-k-mooney: yes, I think you could test the nodeset override on e.g. a nova change, it can be done in the project/check stanza, no need for an extra job definition | 11:50 |
| sean-k-mooney | we can do a pipelien specific variant right in check | 12:15 |
| sean-k-mooney | ill do that to test it with a dnm on top of of 951226 | 12:16 |
| fungi | sean-k-mooney: i also commented similarly on your change but keep in mind that we need to be able to make sure changs we make to release jobs don't break releasing from our oldest maintained stable branches too | 14:33 |
| fungi | as for 951226 the warning from setuptools is premature, only very new versions of tools even support the newer syntax, and now there's a bunch of upheaval in python packaging community discussions about whether it needs to be overhauled again because people can't agree on whether it's supposed to be used to indicate the upstream source/project license or the license(s) of | 14:36 |
| fungi | the distributed packages | 14:36 |
| sean-k-mooney | yep that why i kept all the sable version runign focal | 14:39 |
| sean-k-mooney | i just forgot to add branches:master | 14:39 |
| sean-k-mooney | fungi: so looping back to what prompted this | 14:40 |
| sean-k-mooney | shoudl we hold off on the patch that takashi is proposing | 14:40 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/951226 | 14:41 |
| fungi | yes, i've been trying to pilot it that with https://review.opendev.org/945416 for a much simpler case | 14:41 |
| sean-k-mooney | fungi: on the upstream vs downstream package those should not really ever differ | 14:42 |
| fungi | grr, my wifi is acting up again | 14:42 |
| sean-k-mooney | unless downstream is shiping a fork | 14:42 |
| fungi | sean-k-mooney: it's not upstream vs downstream, it's source code vs the python packages you build from it (which may e.g. include vendored libs with their own licenses) | 14:42 |
| fungi | some people are arguing it should represent the "project" license, some that it should represent the license(s) of what's in the sdist and wheel packages on pypi since it's technically package metadata | 14:43 |
| sean-k-mooney | ok but i think it would be very surpsing for it to be anything other then the lisces of the soruce | 14:43 |
| sean-k-mooney | is the question about if it should be a list or more complex form | 14:44 |
| fungi | in openstack's case, usually (though we do have examples of projects embedding copies of things like javascript libs) | 14:44 |
| fungi | but my point is that the license designation(s) in pyproject.toml are probably going to change again and end up with multiple keys for separating out those different concepts | 14:44 |
| sean-k-mooney | fungi: would you mind leaving a comment to that effect on takashi's patch | 14:45 |
| fungi | i'll try to get to that later today | 14:45 |
| sean-k-mooney | there is little point in changign to it if its going to change again soon | 14:45 |
| fungi | right | 14:46 |
| sean-k-mooney | ill leave a quick comment now just to keep takashi in the loop but i dont have detail so ill just keep it breif | 14:46 |
| fungi | i'm trying to get a link to the discuss.python.org topic, but packet loss here at my workstation it making web browser use nearly impossible at the moment | 14:48 |
| sean-k-mooney | no worreis https://review.opendev.org/c/openstack/nova/+/951226/comments/f20fb8c0_8a07a583 is my summery | 14:49 |
| fungi | https://discuss.python.org/t/90314 | 14:51 |
| fungi | sean-k-mooney: that's ^ the thread i was thinking about | 14:55 |
| opendevreview | Stephen Finucane proposed openstack/releases master: keystoneauth 5.11.1 https://review.opendev.org/c/openstack/releases/+/951423 | 15:57 |
| *** haleyb is now known as haleyb|out | 16:59 | |
| fungi | tkajinam: also, broader discussion before filing mass cross-project packaging changes would be appreciated. as noted i've been experimenting with (careful) migration to newer packaging standards in a handful of opendev projects so far, but the python packaging ecosystem is still figuring things out about some of this such that *i've* not been convinced openstack should try | 17:28 |
| fungi | to forge ahead yet | 17:28 |
| fungi | that's just my (personal/professional) opinion, but it's based on closely following all the discussion happening within the python packaging community. there's a lot of nuance and disagreement that you won't pick up on if you just read the peps/specs | 17:29 |
| clarkb | not a lawyer but: I feel like they are overthinking it. If you're vendoring/bundling/combining in such a way that your package isn't the same license as your "source code" for whatever definition you have of that then I'd argue that your source code functionally has the license of the bundled package anyway | 17:35 |
| clarkb | and then anyone grabbing a specific file/function/method can refer to the license header in that specific file if they really aren't depending on all the other stuff | 17:39 |
| JayF | I'm sure that whatever semantics they define will live in a document that about three dozen people (half of which are in this channel) will read and then most everyone will continue defining license with the minimal amount of thought possible :\ | 17:42 |
| JayF | "What should the license refer to?" is a fine question; but in an ecosystem where none of the metadata is super reliable seems silly | 17:42 |
| sean-k-mooney | JayF: well of course, developers write docuemtnation so the can tell other to go read, why woudl we ever read that ourseleves :) | 20:45 |
| JayF | I think *we* (OpenStack) would, I don't think github user jimbob publishing python-randomLibrary is going to think more than 13 seconds about it :) | 20:45 |
| JayF | and there's a heck of a lot more of the latter than the former on pypi | 20:46 |
| sean-k-mooney | ya, our scale both helps and hurts us wehn it comes to packagign standards | 20:46 |
| sean-k-mooney | we are big engought to have enouch peopel that care | 20:46 |
| sean-k-mooney | but also big enough that making everythign consitent is hard | 20:47 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!