Tuesday, 2015-06-16

*** david-lyle has quit IRC00:24
*** dims has quit IRC00:33
*** dims has joined #openstack-relmgr-office00:46
*** dims has quit IRC01:50
*** david-lyle has joined #openstack-relmgr-office02:08
*** dims has joined #openstack-relmgr-office03:46
*** dims has quit IRC03:51
*** redrobot has quit IRC03:55
ttxdhellmann: I think we can still use "number of integrated releases" as the way to calculate the initial version number, considering pre-integration as 0.x basically06:37
* ttx grabs coffee before entering office hours07:59
*** isviridov_away is now known as isviridov08:00
ttxstevebaker, johnthetubaguy, SergeyLukjanov: I'm available to discuss new server versioning, in case you have concerns about that08:06
ttx(read http://lists.openstack.org/pipermail/openstack-dev/2015-June/067006.html first)08:08
johnthetubaguyttx: 12.0.0 for nova seems good08:34
johnthetubaguyttx: I know there was talk around the milestones, but I think thats more a case of making it clear what you get and what you don't08:35
ttxcool, just making sure you are aware of the change. We'll discuss it at cross-project meeting today, but two pings are better than one08:35
johnthetubaguyttx: thats cool08:35
ttxas far as liberty-1 is concerned, we'll just tag 12.0.0b108:35
ttxi.e. s/2015.2.0/12.0.0/08:35
johnthetubaguyttx: I think thats the best choice right now, sounds good08:36
johnthetubaguyhappy to see us make the move in time for the liberty-1 milestone08:36
ttxbasaiclly we open the door for more independent releases, but expect most to still use the milestone pre-versioning system for liberty08:36
johnthetubaguycool08:36
ttxdenormalizing the release numbers will make the few that jump the shark a lot less funny-looking08:37
ttxbetter to do that in one go08:37
johnthetubaguyttx: very true, its a nice idea08:37
johnthetubaguyttx: I suspect for M we might want something that looks more like a full release, but waiting to see how ironic goes really08:37
*** AzherKhan has joined #openstack-relmgr-office08:39
SergeyLukjanovttx, I think 3.0.0 is ok for Sahara (due to the there were 0.1, 0.2, 0.3, Icehouse, Juno and Kilo releases)09:18
SergeyLukjanovttx, good morning09:18
ttxSergeyLukjanov: cool09:18
*** dims has joined #openstack-relmgr-office09:18
SergeyLukjanovttx, oh, I'm just understand that I was counting from zero09:23
SergeyLukjanovttx, so, we have 2014.1, 2014.2 and 2015.1 tags already09:23
*** dims has quit IRC09:23
SergeyLukjanovttx, in etherpad all 2015.1 versions are missed09:24
SergeyLukjanovttx, as it as  designed?09:24
ttxSergeyLukjanov: hmm, probably not09:25
SergeyLukjanovttx, probably for sahara it'll be better to tag 4.0.0 (0.X for the tags 0.1, 0.2, 0.3; 1.X for 2014.1, 2.X for 2014.2 and 3.X for 2015.1)09:25
SergeyLukjanovit seems more logical for me09:25
ttxyes, will cross-check with dhellmann09:25
SergeyLukjanovttx, yup, I'll post it to ML and I'll be on cross-project meeting09:26
ttxSergeyLukjanov: actually 2014.2 was the first "integrated" version09:35
SergeyLukjanovttx, yeah, but should we skip non-integrated versions?09:35
ttxSergeyLukjanov: so we could consider it's 1.009:36
SergeyLukjanovttx, it's an option, yeah09:36
ttxSergeyLukjanov: I'll rediscuss the ruls with dhellmann09:36
ttxrule*09:36
ttxI think that's what makes the most sense (consider pre-integrated as 0.x and count from 1.0 for integrated)09:37
ttxI'm editing the etherpad to match09:37
SergeyLukjanovttx, ack09:37
SergeyLukjanovttx, so, for the Liberty release we'll have a list of corresponding project versions?09:42
ttxyes09:42
*** AzherKhan has quit IRC10:46
*** dims has joined #openstack-relmgr-office11:21
*** dims has quit IRC11:25
*** dims has joined #openstack-relmgr-office11:29
*** redrobot has joined #openstack-relmgr-office12:42
*** redrobot is now known as Guest7499312:42
*** Guest74993 is now known as el_robot_rojo12:43
*** el_robot_rojo is now known as redrobot12:44
dhellmannttx: hi13:03
* dhellmann tries to figure out why his script missed the 2015 tags13:03
dhellmannah, those are 2015.1.0 and didn't match my regex13:05
ttxanyway, all in all that makes most numbers unchanged :)13:08
ttx(with my suggestion of considering pre-integration as 0.x)13:08
ttxAlso I added to the etherpad what would be missing tags in the git history13:08
ttxlike the 2010.1 Nova Austin13:09
dhellmannyeah, I guess we can count pre-integration releases as 0.x, I hadn't thought of it that way13:10
dhellmannso projects that have never been integrated will start at 1.0?13:11
openstackgerritDoug Hellmann proposed openstack-infra/release-tools: Add show_legacy_releases.sh  https://review.openstack.org/19122813:11
ttxyeah they would13:11
dhellmannok13:11
ttxthat is what I posted in my ML answer13:12
ttxThat will make a designate 1.0.0 which may look funny but I can live with it13:12
ttxnow is as good a time as any13:12
ttxand frankly if they really want to start at 2.0.0 minimum for whatever marketing reason, I don't really care13:13
dhellmannttx: the other projects you list there aren't tagged as release:managed in the governance repo, so that's why I didn't include them13:13
dhellmannbarbican, designate, etc.13:13
ttxyes, I know. In the original submission of release:managed I left them out so that we still had the option to not support them if we really didn't want that13:14
dhellmannok13:14
ttxat least until we had a team discussion about them13:14
ttxbut I managed their kilo releases, so I guess we could/should manage their liberty ones13:14
ttxunless we feel it's too much work13:15
ttxIf we agree, I can push a release:managed tag addition there13:15
dhellmannok, I don't have a problem with that if the teams don't13:15
ttxI'll ask for their feedback on the governance proposal13:15
dhellmannI will also need to re-update the ACLs patch for the libraries from those projects13:15
ttxor we can make an additional dependent patch13:16
dhellmannI'll probably do that13:17
dhellmannttx: did you have any thoughts about the neutron plugins?13:19
ttxthe -aaS things ?13:24
ttxI commented on the ML as well -- they were released in lockstep before, so reusing the neutron version sounds fair there13:24
dhellmannok, I guess that works. I thought they were newer than neutron, though, so I didn't want to assume the version would be the same13:25
ttxdhellmann: At this point mestery always considered those parts of the same "neutron" deliverable13:27
dhellmannok, cool13:27
ttxi.e. you're not supposed to use different versions and expect that to work13:28
ttxI suspect that may evolve in the future13:28
ttxdhellmann: I managed to reach Sergey and John G. during the office hours this morning. Both agreed on their versions.13:47
dhellmannttx: are we sprinting on the project guide today?13:47
ttxthat would be Thursday/Friday13:47
* dhellmann checks why his alarm went off early13:47
* dhellmann might need to just go back to bed today13:47
* ttx takes a break13:48
*** isviridov is now known as isviridov_away14:33
SlickNikttx: Hi — I had a topic to discuss to the cross-project meeting today. Is it too late to add it to the agenda?16:31
SlickNikIt is regarding a follow up on http://lists.openstack.org/pipermail/openstack-dev/2015-June/065731.html16:33
dhellmannSlickNik: that looks like something to bring up in the "vertical projects" open discussion period16:38
SlickNikdhellmann: Sounds good. I'll plan on doing that.16:39
dhellmannSlickNik: great, see you then16:40
*** stevemar has joined #openstack-relmgr-office17:17
* stevemar is standing in for / helping morganfainberg 17:17
stevemardhellmann, proposed server versions of oslo?17:18
dhellmannstevemar: we're re-versioning all of the server projects, like keystone, to drop date-based versioning17:19
dhellmannhttp://lists.openstack.org/pipermail/openstack-dev/2015-June/067082.html17:19
dhellmannand https://etherpad.openstack.org/p/liberty-initial-semver-values17:19
stevemaroh the whole 2015.1 ... and so forth17:19
dhellmannyep17:19
mesterydhellmann: So, the tl;dr on the neutron *aas projects is that they will version DIFFERENTLY than the server? I tend to agree with ihar's comments that they should version the same since we don't have separate API endpoints for htem yet.17:19
stevemaroh gosh yes17:19
dhellmannstevemar: I'm going to be submitting patches using this version numbers tomorrow17:19
dhellmannmestery: no, ttx convinced me it's ok to just use the same values so they'll all start with 7.0.017:20
dhellmannmestery: sorry, that thread got confusing because I was participating in a state of undercaffination17:20
mesterylol17:20
mesterydhellmann: OK, you've got my ack on keeping them all the same, thank you for driving this!17:20
dhellmannmestery: thanks!17:20
stevemardhellmann, i couldn't be happier with the versioning17:21
stevemari really didn't like the date based approach :\17:21
dhellmanncool, so we'll go with keystone as 8.0.017:21
stevemarmakes sense to me. liberty will be our 8th release17:21
dhellmannright, that's the idea17:21
morganfainbergdhellmann: I want version 13.0 (jk)17:21
dhellmannmorganfainberg: exceptions can be made, but you have to earn them17:22
* dhellmann sounds like he's selling indulgences17:22
morganfainbergdhellmann: /put ptl card on table and stamps feet (does that count? :P17:22
mesterylol17:22
* dhellmann may have been watching too much Wolf Hall17:22
morganfainberg8.0 sounds good.17:22
dhellmannmorganfainberg: excellent, thanks17:22
stevemardhellmann, so if something goes awry, then it's 8.0.1 ?17:23
dhellmannor 8.1 or whatever, depending on what has merged17:23
stevemarcool cool17:23
stevemarkeeps things more pythony17:23
dhellmannactually, we'll be doing pre-release versioning still, so L1 will be 8.0.0b1 I think17:23
stevemarohhh17:23
morganfainbergIs that going to fubar pip up for install because 2015.x.x > 8.0.0?17:23
stevemarfancy17:23
dhellmannbut *after* liberty, the stable releases will be semver17:23
morganfainbergOr whatever prev versions were.17:23
morganfainbergOh wait nvm.17:24
morganfainbergdeep.17:24
dhellmannmorganfainberg: it will for upgrades, although apparently pip supports epochs, too17:24
morganfainbergDerp*17:24
morganfainbergWe don't put keystone on pypi17:24
dhellmannwell, that's part of the move, actually17:24
morganfainbergBecause... Go look what keystone is there :P17:24
stevemarhttps://pypi.python.org/pypi/Keystone :P17:24
morganfainbergWe don't own it. It is a "framework".17:24
stevemarthat's totally us, i dunno what you're talking about17:25
dhellmannkeystone is all things to all people17:25
morganfainbergI hear we are a key value store over rest.17:25
morganfainbergBut implemented without the basic functionality of say memcache.17:25
* morganfainberg stops being snarky and goes back to AFK.17:26
morganfainbergdhellmann: actually. Hmm will get back to you shortly.17:26
morganfainbergHave a thought...17:26
* dhellmann stands by for thought download17:29
morganfainbergNope. Lost it. :(17:51
morganfainbergOh well. Thought is gone.17:51
dhellmannttx: do any of the scripts in release-tools help with updating the version number in setup.cfg, or should I just do those by hand?18:24
ttxdhellmann: no, none18:52
dhellmannttx: ok, it's just a few so I'll do them by hand19:10
*** Daviey has quit IRC21:30
dhellmannttx: it looks like we need to tag all of the projects changing away from date-based releases with a version less than the new version they are working up to in order to make pbr happy. So I am planning to use X.0.0a0 as a tag for all of those projects. Then after we add the setup.cfg change, we will get versions like X.0.0a1.devN and then we can tag X.0.0a1 at L1 or we can just leave the tagging for later.21:55
dhellmannttx: let me know if you like the a0 or if I should go ahead and use a1 for now or if you don't care one way or the other. :-)21:56
lifelessdhellmann: you're so much more polite than I... I'd have JFDI'd ;)21:56
lifelessdhellmann: am I accepted into the team at this point? I'm not in https://review.openstack.org/#/admin/groups/11,members21:56
dhellmannlifeless: I'm new on the team. :-)21:56
lifelessttx: ^21:57
dhellmannlifeless: oh, I was planning to add you to the new library-release team, but hadn't thought about that one. I'll defer to ttx as PTL21:57
lifelessoh21:57
lifelessdidn't realise there were two21:57
lifelesswhatever works for ttx21:57
dhellmannlifeless: yeah, the new team won't exist until the acl patch lands and gerrit creates it as a side-effect21:58
dhellmannor maybe fungi creates those after the patches land, but either way, after the patch21:58
ttxlet's do library-release for now22:00
dhellmannttx: ack22:01
dhellmannttx: you can think about the version number thing tomorrow morning, I won't be doing that until my morning so there's time22:01
ttxdhellmann: on the tag thing22:01
dhellmannoh, unless you have an answer ready :-)22:01
ttxwas wondering what would happen if we just tagged X.0.0b1 and then change setup.cfg22:02
ttxinstead of X.0.0a1, setup.cfg; X.0.0b122:02
dhellmannoh, I wasn't using beta versions in the setup.cfg22:02
dhellmannso you mean tag b1 on next thursday?22:02
ttxright, you shouldn't use beta version in setup.cfg22:03
dhellmannand then after the tag, change the setup.cfg to have X.0.0?22:03
ttxyes22:03
dhellmannI think that would probably work. lifeless ?22:03
ttxI guess the problem is that you generate crappy 2015.2.0-foo-bar versions between X.0.0b1 and the setup.cfg change22:03
ttxsince that wouldn't be atomic22:04
dhellmannlet me test that22:04
ttxso it's a bit ugly, but wouldn't be the first time we generate a random crappy version22:04
dhellmannif I tag 1.0.0b1 and then commit the setup.cfg change I get 1.0.0.0b2.dev122:05
ttxalso we could ask the PTLs to approve the setup.cfg bump first thing after we push the tag22:05
ttxdhellmann: right, so that would work as well22:05
ttxand avoid the extraneous a1 tag22:05
dhellmannthat makes the timing a bit trickier, which might be a reason to live with the alpha tag, but either way should get us a good beta tag on thursday22:06
ttxIf it's a technical tag we could (I think) remove it from history22:07
dhellmannthat might break folks doing ci/cd22:07
ttxhmm, yeah22:07
ttxso option 1 is to tag 1.0.0a1 before setup.cfg and 1.0.0b1 tag, but results in extraneous tag22:08
ttxoption 2 is to tag 1.0.0b1 and then bump setup.cfg22:08
lifelesssorry, stepped away for a sec22:08
lifelessreading22:08
ttxboth cases we'll generate "wrong" versions for any commit between the tag and the setup.cfg bump22:08
ttxi.e. 2015.2.0-somethign-something after the 1.0.0a1 or 1.0.0b1 tag22:09
lifelessyou can't have the same tag versionin setup.cfg as you've tagged.22:09
ttxlifeless: sure22:09
lifelessor are you saying 'wait until the beta is cut before updating setup.cfg ?22:10
dhellmannttx: no, once we tag the 2015 versions go away22:10
ttxwe would tag 1.0.0b1, then push 1.0.0 to setup.cfg22:10
lifelessso22:10
lifelessthe thing thats weird there22:10
ttxdhellmann: not for intermediary commits22:10
dhellmannoh, hrm, maybe they only go away because I'm sitting on a tag -- yeah22:10
lifelessis that the first commit after the tag would be back in the 2015 space22:10
ttxlifeless: yes, that's what I expected22:10
ttxexcept if the next commit is the setup.cfg bump, right ?22:11
lifelessI think thats confusing, and it would make getting those first commits to be the setup.cfg change really critical22:11
lifelessI don't like that22:11
ttxlifeless: but you get the exact same effect if you follow option 122:11
lifelessits also confusing because the tagged version will have a wildly different version = line22:11
lifelessttx: for a tag we're not announcing and not telling folk to use22:11
lifelessttx: or test22:11
lifelessttx: thats a big social difference IMO22:11
ttxyou'll have a 2015.2 version for any commit between 1.0.0a1 tag and setup.cfg bump to 1.0.022:11
ttxlifeless: that's fair22:12
lifelessthere is a way around this22:12
lifelessremove the version = from setup.cfg. Tag the new lower bound. Add version = back into setup.cfg22:12
lifelessbut its more steps for marginal gain.22:12
lifelessand may involve two version sequence rewinds if the current version= in setup.cfg is higher than pbr would generate itself.22:13
ttxok, so I'll jump to bed. I'm fine with a1 tags as a workaround. Would prefer if we did not add extraneous tags but I'm fine with it22:13
dhellmannremoving the version from setup.cfg for barbican causes the version to go backwards from 2015.2.0.dev101 to 2015.1.1.dev10122:14
ttxdhellmann: I think we shouldn't remove the setup.cfg version. Just use a1 tags22:14
dhellmannyou know, another option is to do the tag and then just remove the entry from setup.cfg entirely and rely on tags from now on22:15
dhellmannI've so far not wanted to do that, because it's a much bigger procedural change22:15
ttxdhellmann: sounds risky. I prefer the a1 trick22:15
dhellmannttx: agreed. a0 or a1?22:15
ttxwhatever :)22:16
dhellmannthe a0 tag will produce a1 versions for later commits22:16
dhellmannI guess it doesn't really matter, so maybe a1 is clearer as a tag22:16
ttxa0 sounds good for a null tag22:16
ttxyour call22:16
ttxa0/a122:16
* ttx disappears22:16
dhellmannk22:16
dhellmanngnite22:16
* dhellmann heads out for dinner22:17
ttxgood end of day!22:17
*** openstackgerrit has quit IRC22:38
*** openstackgerrit has joined #openstack-relmgr-office22:39
SlickNikttx / dhellmann: Is the TC meeting next week on Monday (22nd) instead of Tue (23rd)? The reason I'm asking is because the wiki seemed to indicate that (https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee) and I wanted to check it wasn't a typo.22:54
SlickNikThanks!22:54
*** sdague has quit IRC23:12
*** sdague has joined #openstack-relmgr-office23:24
*** stevemar has quit IRC23:44
*** stevemar has joined #openstack-relmgr-office23:44

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