*** AJaeger has joined #openstack-relmgr-office | 07:25 | |
*** AJaeger has quit IRC | 07:25 | |
*** AJaeger has joined #openstack-relmgr-office | 07:25 | |
*** openstackgerrit has quit IRC | 09:53 | |
*** openstackgerrit has joined #openstack-relmgr-office | 09:54 | |
*** dims has joined #openstack-relmgr-office | 10:37 | |
*** Kiall has quit IRC | 11:35 | |
*** Kiall has joined #openstack-relmgr-office | 11:35 | |
dims | dhellmann: ttx: i've updated https://etherpad.openstack.org/p/library-releases with notes for oslo.library releases for this week | 11:46 |
---|---|---|
pabelanger | morning | 12:42 |
ttx | meeting in #openstack-meeting | 13:01 |
dims | ttx: dhellmann - fungi requested python-keystoneclient 1.1.1 stable point release requested to un-wedge stable/juno devstack per bug 1468395 | 13:47 |
openstack | bug 1468395 in python-keystoneclient "Versions of oslo.i18n higher than 1.17.0 cause ImportError" [Undecided,Confirmed] https://launchpad.net/bugs/1468395 | 13:47 |
dims | ttx: dhellmann: i'll take care of it | 13:49 |
dhellmann | dims: ack, thanks | 13:54 |
*** superdan is now known as dansmith | 13:57 | |
dims | dhellmann: looks like they need stable/juno (changes are http://paste.openstack.org/show/324859/) and version will be 1.1.1 | 13:57 |
dims | which does seem to fit in ok with the range (python-keystoneclient>=0.10.0,<1.2.0) specified in https://github.com/openstack/requirements/blob/stable/juno/global-requirements.txt#L112 | 14:00 |
dhellmann | dims: ok, sounds good | 14:00 |
dims | thanks | 14:00 |
dhellmann | ttx: on release version tracking, maybe we can do that in a part of the new releases repository | 14:01 |
ttx | dhellmann: last week is a blur at this point but we touched on that topic IIRC (how to actually code that series/version mapping tool) | 14:02 |
dhellmann | I was supposed to do some research into how easy/hard it is to get tags from git and organize them by branch | 14:02 |
dims | "./release_postversion.sh juno 1.1.1 04543e7 python-keystoneclient" | 14:02 |
dhellmann | dims: ++ | 14:03 |
ttx | dhellmann: sounds promising if we have enough data in. If we don't, we might want to. Like the content of the tag could include extra daat | 14:03 |
ttx | or data | 14:03 |
ttx | one more possibility offered by centrally tagging | 14:03 |
dhellmann | ttx: I wonder if this is a use case for jeblair | 14:04 |
dhellmann | oops | 14:04 |
dhellmann | jeblair's idea of keeping all release tags in the files in the repo? | 14:04 |
ttx | we could have historical data built in the tool, and then derive future from tags contents | 14:04 |
ttx | dhellmann: yes, I tried to wrap my head around that and see if those two birds could be killed with one stone | 14:05 |
dhellmann | I think they probably can, although combining that with deliverables will be interesting | 14:05 |
ttx | your current proposal has one file per repo+branch right ? | 14:06 |
dhellmann | yes | 14:06 |
dims | dhellmann: on its way | 14:06 |
dhellmann | dims: thanks for handling that | 14:06 |
dims | my pleasure dhellmann | 14:07 |
ttx | and we are saying we could do deliverable+branch+version | 14:07 |
dhellmann | ttx: I think we really need one file per deliverable per series, with the entire tag history for that series in the file | 14:07 |
ttx | that sounds manageable | 14:07 |
ttx | so really deliverable+series | 14:07 |
dhellmann | yes | 14:08 |
ttx | with some magic to recognize that if stable/liberty isn't there yet, master is probably the good target | 14:08 |
ttx | sounds like it wouldn't get us into files of dramatic length | 14:08 |
dhellmann | the release notes tool uses a branch name to figure out what notes to include, but we can put the branch name in the file where it's needed | 14:08 |
dhellmann | or what you said :-) | 14:08 |
ttx | that would make the tool pretty easy, and even make the repo human-consumable | 14:09 |
dhellmann | and it would be easy enough to render the results using sphinx, too | 14:09 |
ttx | (as long as it's not xml) | 14:09 |
dhellmann | heh | 14:09 |
ttx | ok, I think we are onto something here. | 14:10 |
dhellmann | we'll want something to extract the history of the repos that we have now, right? | 14:10 |
ttx | the automation will have to react to tag additions in files rather than "any change", so probably check existing tags. But that's probably a good check anyway | 14:10 |
ttx | dhellmann: yes, would be good to seed history in | 14:11 |
ttx | or at least the good-looking tags history | 14:11 |
dhellmann | yeah, jeblair wanted it more idempotent anyway | 14:11 |
ttx | let's avoid the technical tags :) | 14:11 |
dhellmann | I resisted because of the pain in launchpad, but maybe we can bypass that | 14:11 |
ttx | it's really a "release" thing, not a tag thing. A release may result in tag(s) | 14:11 |
dhellmann | I'll see if I can write something to generate some sample files | 14:12 |
ttx | ok, I can help too, sounds easy enough for my limited skills | 14:12 |
ttx | dhellmann: are you doing another patchset on the review to propose that ? Or just get that spec landed and iterate from it ? | 14:13 |
dhellmann | ttx: I can do another patchset, if you think that's more likely to get the spec approved. I gather the infra team would like reality documented to some degree anyway. | 14:14 |
dhellmann | ttx: I'll write another draft with new sample files | 14:15 |
ttx | dhellmann: cool | 14:17 |
dims | dhellmann: the library got released but i had trouble with karma for milestones - http://paste.openstack.org/show/324931/ | 14:18 |
dhellmann | ttx: what launchpad group does dims need to be in for ^^ ? | 14:19 |
dhellmann | dims: I can re-run the script and see if that part works for me while we get your acls sorted out | 14:19 |
ttx | hmm | 14:20 |
ttx | openstack-release should be ok, let me add him | 14:20 |
ttx | done | 14:20 |
dhellmann | dims: ok, why don't you run it again to test now that ttx has updated you | 14:20 |
*** dims has quit IRC | 14:21 | |
ttx | dhellmann: for deliverables, https://etherpad.openstack.org/p/I22WK9NSD1 ends up being the most consise/elegant, but means we'll have to handle two cases in tools (old-style and new-style declarations) | 14:23 |
ttx | creating deliverables for every single-repo things will add a lot of boilerplate | 14:24 |
*** dims has joined #openstack-relmgr-office | 14:24 | |
ttx | oh. or... | 14:24 |
dhellmann | I'm not sure I like having 2 "types" in the projects list | 14:24 |
dims | sorry, network hiccup | 14:25 |
dhellmann | dims: np, I proposed that you re-run the script now that ttx has updated your acls | 14:25 |
dims | ack | 14:26 |
dims | worked fine! thanks | 14:26 |
dhellmann | dims: good | 14:29 |
dhellmann | dims: I've also encountered issues with private security bugs in the past, but there are patches up to make the tool ignore those errors for now | 14:29 |
dhellmann | ttx: I sort of like my "'deliverable' field on project/repo" option on line 59 | 14:30 |
dims | dhellmann: sound good thanks | 14:31 |
ttx | dhellmann: posted the non-abckward compat version on top | 14:32 |
dhellmann | ok, I sort of like that, too | 14:32 |
ttx | I think none of the options is backward compatible anyway | 14:33 |
dhellmann | not if we're adding another place where we can put tags, no | 14:33 |
ttx | yeah | 14:33 |
ttx | heck we can even spare the name | 14:34 |
ttx | andthen I win as most concise :P | 14:34 |
dhellmann | I think you're going to want a name, though, because we'll use that to generate headings and things | 14:35 |
dhellmann | we'll probably have descriptions, even | 14:35 |
* ttx sobs | 14:35 | |
ttx | The name is slightly redundant though. Could be optional for one-repo things. | 14:35 |
ttx | ooh | 14:36 |
ttx | you win | 14:36 |
dhellmann | although using a list like you had it lets us enforce the order | 14:37 |
dhellmann | we might want that for generating the html | 14:37 |
dhellmann | but I suspect just sorting them will be good enough | 14:37 |
ttx | yeah, the question is more, how much of a tool ecosystem have we grown around that file already | 14:38 |
*** AJaeger has left #openstack-relmgr-office | 14:38 | |
dhellmann | I think all of it is in release-tools | 14:38 |
ttx | and governance | 14:38 |
ttx | so we can probably change the governance side in one go | 14:38 |
ttx | ok, I'll look deeper into that | 14:38 |
ttx | thanks for your help! | 14:38 |
dhellmann | true, i was just thinking of the sphinx stuff there, but jogo wrote some validation scripts | 14:39 |
dhellmann | dims: reviewing https://etherpad.openstack.org/p/library-releases, all of those version numbers look good. I left a couple of comments, but I say go ahead with the versions you've picked | 14:52 |
dims | dhellmann: thanks! will cut them this afternoob | 14:52 |
dims | noon :) | 14:52 |
dhellmann | :-) | 14:54 |
*** david-ly_ is now known as david-lyle | 15:27 | |
morganfainberg | dims: I think I like afternoob better :P | 15:29 |
morganfainberg | Noon implode | 15:30 |
morganfainberg | Noon implies a fixed time. | 15:30 |
dims | LOL | 15:31 |
dhellmann | morganfainberg: where are we with the stable/kilo release of keystonemiddleware? | 15:33 |
morganfainberg | dhellmann: should be good to go | 15:33 |
morganfainberg | Just needs a. Tag | 15:34 |
morganfainberg | Unless something else broke since Thursday | 15:34 |
morganfainberg | (I'm not aware of anything else broken) | 15:34 |
dhellmann | morganfainberg: does http://paste.openstack.org/show/325117/ look like what you expect? | 15:34 |
dhellmann | version # 1.5.2 | 15:34 |
morganfainberg | Yep. The requirements update is the important part n | 15:35 |
dhellmann | ok, I'll tag that now | 15:35 |
morganfainberg | Thnx! | 15:36 |
dhellmann | morganfainberg: No 'setup.py' file found in /mnt/repos/openstack-infra/release-tools/release-tag-keystonemiddleware-4lg/keystonemiddleware/1.5.1 | 15:36 |
morganfainberg | Huh. | 15:36 |
morganfainberg | It's there in the repo. | 15:38 |
morganfainberg | https://github.com/openstack/keystonemiddleware/blob/stable/kilo/setup.py ? | 15:38 |
morganfainberg | Is this the -x thing? | 15:38 |
morganfainberg | Or whatever. | 15:38 |
dhellmann | yeah, probably a bug in my script | 15:38 |
dhellmann | it's just the release notes, so I'll do those by hand | 15:38 |
morganfainberg | Ok. | 15:39 |
morganfainberg | Thanks again! :) | 15:39 |
openstackgerrit | Doug Hellmann proposed openstack-infra/release-tools: Fix --stable flag https://review.openstack.org/196712 | 15:45 |
dhellmann | morganfainberg: done | 15:45 |
morganfainberg | dhellmann: ack | 15:46 |
*** openstackgerrit has quit IRC | 18:30 | |
*** openstackgerrit has joined #openstack-relmgr-office | 18:30 | |
*** Rockyg has joined #openstack-relmgr-office | 18:55 | |
dims | dhellmann: o.vo messed things up, need to exclude version released today - https://review.openstack.org/#/c/196826/ | 19:44 |
dhellmann | dims: approved | 19:47 |
dims | thanks dhellmann | 19:47 |
* dims goes back to check why his tests did not show this failure | 19:47 | |
*** Rockyg has quit IRC | 21:09 | |
*** Rockyg has joined #openstack-relmgr-office | 22:09 | |
*** Rockyg has quit IRC | 22:12 | |
*** Rockyg has joined #openstack-relmgr-office | 22:13 | |
*** wshao has joined #openstack-relmgr-office | 22:19 | |
wshao | dhellman I have a question on openstack project naming vs pypi. Comapss is the project in stackforge that I'd like to move to openstack. It contains python package, javascript webapp, and chef cookbooks in 3 different stackforge repos. For pypi package registration, compass is used by another py package. What shall I do? | 22:21 |
dhellmann | wshao: what does your stackforge/compass library do? | 22:29 |
wshao | dhellmann: it is a project that automates installation of openstack and other distributed systems | 22:30 |
dhellmann | wshao: ok. you have a few options | 22:30 |
dhellmann | you could rename the project, which I know isn't a great option | 22:30 |
dhellmann | you could rename just the python package(s) so they have something else in the name in addition to compass (compass-core, compass-blah, compass-foo, etc.) | 22:31 |
wshao | on the other thread, someone says some openstack projects have not registered in pypi. Is that a must-have requirement? | 22:31 |
dhellmann | that may well end up being confusing | 22:31 |
wshao | ok. i will try compass-core. | 22:31 |
wshao | thanks! | 22:31 |
dhellmann | wshao: if you are going to release python packages, you need a unique name on pypi, so yes, you should register them there | 22:32 |
wshao | In that case, on the openstack side, can I still keep "compass" as the project name (in projects.yaml etc)? | 22:32 |
dhellmann | wshao: see http://docs.openstack.org/infra/manual/creators.html | 22:32 |
wshao | yes, I am following the steps on that page | 22:32 |
dhellmann | wshao: the repository name and python dist name can be different, but you don't want them too different. So I wouldn't call the python dist name something *completely* different from compass | 22:33 |
dhellmann | unless you end up renaming the package entirely | 22:33 |
wshao | ok. cool. thanks! | 22:33 |
*** dims_ has joined #openstack-relmgr-office | 22:55 | |
*** dims has quit IRC | 22:59 | |
*** dims_ has quit IRC | 23:00 | |
wshao | On jenkin config, I am editing jenkins/jobs/projects.yaml for moving compass to openstack. Shall I just move the compass block from stackforge section to openstack section? If I only add one under "openstack", I worry that there are two blocks with same name "compass" | 23:01 |
wshao | dhellmann: ^^ | 23:01 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!