Monday, 2015-06-29

*** AJaeger has joined #openstack-relmgr-office07:25
*** AJaeger has quit IRC07:25
*** AJaeger has joined #openstack-relmgr-office07:25
*** openstackgerrit has quit IRC09:53
*** openstackgerrit has joined #openstack-relmgr-office09:54
*** dims has joined #openstack-relmgr-office10:37
*** Kiall has quit IRC11:35
*** Kiall has joined #openstack-relmgr-office11:35
dimsdhellmann: ttx: i've updated https://etherpad.openstack.org/p/library-releases with notes for oslo.library releases for this week11:46
pabelangermorning12:42
ttxmeeting in #openstack-meeting13:01
dimsttx: dhellmann - fungi requested python-keystoneclient 1.1.1 stable point release requested to un-wedge stable/juno devstack per bug 146839513:47
openstackbug 1468395 in python-keystoneclient "Versions of oslo.i18n higher than 1.17.0 cause ImportError" [Undecided,Confirmed] https://launchpad.net/bugs/146839513:47
dimsttx: dhellmann: i'll take care of it13:49
dhellmanndims: ack, thanks13:54
*** superdan is now known as dansmith13:57
dimsdhellmann: looks like they need stable/juno (changes are http://paste.openstack.org/show/324859/) and version will be 1.1.113:57
dimswhich 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#L11214:00
dhellmanndims: ok, sounds good14:00
dimsthanks14:00
dhellmannttx: on release version tracking, maybe we can do that in a part of the new releases repository14:01
ttxdhellmann: 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
dhellmannI was supposed to do some research into how easy/hard it is to get tags from git and organize them by branch14:02
dims"./release_postversion.sh juno 1.1.1 04543e7 python-keystoneclient"14:02
dhellmanndims: ++14:03
ttxdhellmann: 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 daat14:03
ttxor data14:03
ttxone more possibility offered by centrally tagging14:03
dhellmannttx: I wonder if this is a use case for jeblair14:04
dhellmannoops14:04
dhellmannjeblair's idea of keeping all release tags in the files in the repo?14:04
ttxwe could have historical data built in the tool, and then derive future from tags contents14:04
ttxdhellmann: yes, I tried to wrap my head around that and see if those two birds could be killed with one stone14:05
dhellmannI think they probably can, although combining that with deliverables will be interesting14:05
ttxyour current proposal has one file per repo+branch right ?14:06
dhellmannyes14:06
dimsdhellmann: on its way14:06
dhellmanndims: thanks for handling that14:06
dimsmy pleasure dhellmann14:07
ttxand we are saying we could do deliverable+branch+version14:07
dhellmannttx: I think we really need one file per deliverable per series, with the entire tag history for that series in the file14:07
ttxthat sounds manageable14:07
ttxso really deliverable+series14:07
dhellmannyes14:08
ttxwith some magic to recognize that if stable/liberty isn't there yet, master is probably the good target14:08
ttxsounds like it wouldn't get us into files of dramatic length14:08
dhellmannthe 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 needed14:08
dhellmannor what you said :-)14:08
ttxthat would make the tool pretty easy, and even make the repo human-consumable14:09
dhellmannand it would be easy enough to render the results using sphinx, too14:09
ttx(as long as it's not xml)14:09
dhellmannheh14:09
ttxok, I think we are onto something here.14:10
dhellmannwe'll want something to extract the history of the repos that we have now, right?14:10
ttxthe 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 anyway14:10
ttxdhellmann: yes, would be good to seed history in14:11
ttxor at least the good-looking tags history14:11
dhellmannyeah, jeblair wanted it more idempotent anyway14:11
ttxlet's avoid the technical tags :)14:11
dhellmannI resisted because of the pain in launchpad, but maybe we can bypass that14:11
ttxit's really a "release" thing, not a tag thing. A release may result in tag(s)14:11
dhellmannI'll see if I can write something to generate some sample files14:12
ttxok, I can help too, sounds easy enough for my limited skills14:12
ttxdhellmann: are you doing another patchset on the review to propose that ? Or just get that spec landed and iterate from it ?14:13
dhellmannttx: 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
dhellmannttx: I'll write another draft with new sample files14:15
ttxdhellmann: cool14:17
dimsdhellmann: the library got released but i had trouble with karma for milestones - http://paste.openstack.org/show/324931/14:18
dhellmannttx: what launchpad group does dims need to be in for ^^ ?14:19
dhellmanndims: I can re-run the script and see if that part works for me while we get your acls sorted out14:19
ttxhmm14:20
ttxopenstack-release should be ok, let me add him14:20
ttxdone14:20
dhellmanndims: ok, why don't you run it again to test now that ttx has updated you14:20
*** dims has quit IRC14:21
ttxdhellmann: 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
ttxcreating deliverables for every single-repo things will add a lot of boilerplate14:24
*** dims has joined #openstack-relmgr-office14:24
ttxoh. or...14:24
dhellmannI'm not sure I like having 2 "types" in the projects list14:24
dimssorry, network hiccup14:25
dhellmanndims: np, I proposed that you re-run the script now that ttx has updated your acls14:25
dimsack14:26
dimsworked fine! thanks14:26
dhellmanndims: good14:29
dhellmanndims: 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 now14:29
dhellmannttx: I sort of like my "'deliverable' field on project/repo" option on line 5914:30
dimsdhellmann: sound good thanks14:31
ttxdhellmann: posted the non-abckward compat version on top14:32
dhellmannok, I sort of like that, too14:32
ttxI think none of the options is backward compatible anyway14:33
dhellmannnot if we're adding another place where we can put tags, no14:33
ttxyeah14:33
ttxheck we can even spare the name14:34
ttxandthen I win as most concise :P14:34
dhellmannI think you're going to want a name, though, because we'll use that to generate headings and things14:35
dhellmannwe'll probably have descriptions, even14:35
* ttx sobs14:35
ttxThe name is slightly redundant though. Could be optional for one-repo things.14:35
ttxooh14:36
ttxyou win14:36
dhellmannalthough using a list like you had it lets us enforce the order14:37
dhellmannwe might want that for generating the html14:37
dhellmannbut I suspect just sorting them will be good enough14:37
ttxyeah, the question is more, how much of a tool ecosystem have we grown around that file already14:38
*** AJaeger has left #openstack-relmgr-office14:38
dhellmannI think all of it is in release-tools14:38
ttxand governance14:38
ttxso we can probably change the governance side in one go14:38
ttxok, I'll look deeper into that14:38
ttxthanks for your help!14:38
dhellmanntrue, i was just thinking of the sphinx stuff there, but jogo wrote some validation scripts14:39
dhellmanndims: 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 picked14:52
dimsdhellmann: thanks! will cut them this afternoob14:52
dimsnoon :)14:52
dhellmann:-)14:54
*** david-ly_ is now known as david-lyle15:27
morganfainbergdims: I think I like afternoob better :P15:29
morganfainbergNoon implode15:30
morganfainbergNoon implies a fixed time.15:30
dimsLOL15:31
dhellmannmorganfainberg: where are we with the stable/kilo release of keystonemiddleware?15:33
morganfainbergdhellmann: should be good to go15:33
morganfainbergJust needs a. Tag15:34
morganfainbergUnless something else broke since Thursday15:34
morganfainberg(I'm not aware of anything else broken)15:34
dhellmannmorganfainberg: does http://paste.openstack.org/show/325117/ look like what you expect?15:34
dhellmannversion # 1.5.215:34
morganfainbergYep. The requirements update is the important part n15:35
dhellmannok, I'll tag that now15:35
morganfainbergThnx!15:36
dhellmannmorganfainberg: No 'setup.py' file found in /mnt/repos/openstack-infra/release-tools/release-tag-keystonemiddleware-4lg/keystonemiddleware/1.5.115:36
morganfainbergHuh.15:36
morganfainbergIt's there in the repo.15:38
morganfainberghttps://github.com/openstack/keystonemiddleware/blob/stable/kilo/setup.py ?15:38
morganfainbergIs this the -x thing?15:38
morganfainbergOr whatever.15:38
dhellmannyeah, probably a bug in my script15:38
dhellmannit's just the release notes, so I'll do those by hand15:38
morganfainbergOk.15:39
morganfainbergThanks again! :)15:39
openstackgerritDoug Hellmann proposed openstack-infra/release-tools: Fix --stable flag  https://review.openstack.org/19671215:45
dhellmannmorganfainberg: done15:45
morganfainbergdhellmann: ack15:46
*** openstackgerrit has quit IRC18:30
*** openstackgerrit has joined #openstack-relmgr-office18:30
*** Rockyg has joined #openstack-relmgr-office18:55
dimsdhellmann: o.vo messed things up, need to exclude version released today - https://review.openstack.org/#/c/196826/19:44
dhellmanndims: approved19:47
dimsthanks dhellmann19:47
* dims goes back to check why his tests did not show this failure19:47
*** Rockyg has quit IRC21:09
*** Rockyg has joined #openstack-relmgr-office22:09
*** Rockyg has quit IRC22:12
*** Rockyg has joined #openstack-relmgr-office22:13
*** wshao has joined #openstack-relmgr-office22:19
wshaodhellman 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
dhellmannwshao: what does your stackforge/compass library do?22:29
wshaodhellmann: it is a project that automates installation of openstack and other distributed systems22:30
dhellmannwshao: ok. you have a few options22:30
dhellmannyou could rename the project, which I know isn't a great option22:30
dhellmannyou 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
wshaoon the other thread, someone says some openstack projects have not registered in pypi. Is that a must-have requirement?22:31
dhellmannthat may well end up being confusing22:31
wshaook. i will try compass-core.22:31
wshaothanks!22:31
dhellmannwshao: if you are going to release python packages, you need a unique name on pypi, so yes, you should register them there22:32
wshaoIn that case, on the openstack side, can I still keep "compass" as the project name (in projects.yaml etc)?22:32
dhellmannwshao: see http://docs.openstack.org/infra/manual/creators.html22:32
wshaoyes, I am following the steps on that page22:32
dhellmannwshao: 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 compass22:33
dhellmannunless you end up renaming the package entirely22:33
wshaook. cool. thanks!22:33
*** dims_ has joined #openstack-relmgr-office22:55
*** dims has quit IRC22:59
*** dims_ has quit IRC23:00
wshaoOn 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
wshaodhellmann: ^^23:01

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!