Tuesday, 2015-07-07

*** dims has joined #openstack-relmgr-office00:01
*** dims has quit IRC00:50
*** dims has joined #openstack-relmgr-office00:58
*** dims has quit IRC03:39
*** dims has joined #openstack-relmgr-office04:40
*** dims_ has joined #openstack-relmgr-office04:41
*** dims has quit IRC04:45
*** dims_ has quit IRC04:46
*** ig0r_ has joined #openstack-relmgr-office05:51
*** ig0r__ has quit IRC05:55
*** dims has joined #openstack-relmgr-office07:43
*** dims has quit IRC07:48
ttxOffice hours start, yay! grabbing coffee08:06
*** dims has joined #openstack-relmgr-office09:44
*** dims_ has joined #openstack-relmgr-office09:45
*** dims__ has joined #openstack-relmgr-office09:46
*** dims has quit IRC09:48
*** dims_ has quit IRC09:50
*** dims__ has quit IRC09:50
*** dims has joined #openstack-relmgr-office10:46
*** dims has quit IRC10:51
*** dims has joined #openstack-relmgr-office12:02
*** dims has quit IRC12:07
*** dims has joined #openstack-relmgr-office13:19
dhellmanndims: sorry, missed your note yesterday, but it looks like a nice pile of releases went out13:37
dhellmannttx: I'm probably going to have to miss the cross-project meeting today13:37
ttxdhellmann: sure, np13:38
ttxdhellmann: let me know when you have 10 minutes, I have a few topics to discuss with you13:38
dhellmannttx: now is good13:38
dhellmanndid you talk with mestery about the release ACL change for the neutron libs, or is that his initiative?13:38
dimsdhellmann: i accidently gave a big boost to tooz, taskflow and oslo.vmware. though we did not break anything, we will have to cut 2.x for them next (instead of 1.x)13:39
ttxdhellmann: it is his initiative. One of the topics I wanted to discuss with you actually13:39
dhellmanndims: perhaps we should re-evaluate how we make the proposed breaking changes instead of automatically incrementing the version13:39
dhellmannttx: ok13:39
ttxin particular in which release model bucket we'd like them in13:40
ttxAll those things are release:independent13:40
ttxso my understanding is that there is no "final" release at the end of the cycle13:41
dhellmannI suppose his change implies a release:managed change in governance. Maybe we should ask for that before the ACL change, or as part of it.13:41
dhellmannhmm, so no stable branches?13:41
ttxso far we only accepted to "manage" things that followed the cycle (with miletsones or with intermediary)13:41
ttxmaybe it's an oversight, due to the weirdness of the current tags13:42
dhellmannthat's a good point13:42
ttxmaybe it's not13:42
* dhellmann thinks about whether there's any reason to have managed independent projects13:42
ttxMy take is we shouldn't manage things that are purely "independent"13:42
ttxour added value there is limited, better focus on things that have cycle adherence13:43
dhellmannit's probably too early for mestery to be online to talk to him directly13:43
ttxso I guess I should clarify the release model with him there13:43
dhellmannI agree, but I'm thinking about whether there are *any* exceptions -- these libs would not be exceptions13:44
ttxif they end up being more like libraries (cycle-with-intermediary) then we could definitely manage them13:44
dhellmannright13:44
dhellmannok, I'll go change my vote on that patch13:44
ttxNext topic is connected13:45
ttxNew release model tags @ https://review.openstack.org/#/c/198789/13:45
ttxI'd like some early review on the WIP from you before I start trying to edit projects.yaml to match13:46
ttxsince that's likely to be a painful patch to push13:46
dhellmannok, I'll look at those during my office hours today13:46
ttxLast topic is the Tokyo CFP and if we'd propose a Liberty release management talk13:47
dhellmannyes, I saw the reminder for that yesterday afternoon13:47
ttxI think we can try, so I'll do an etherpad to collect all the things we'd like to communicate13:47
ttxand see if there is enough to justify a talk there13:47
ttxI'll pm you the link13:48
dhellmannyes, I was thinking about your point that there won't be any time not overlapping with the design summit, but I think we should do something more to publicize the release model changes13:48
ttxideally we'd brainstorm on that befoire the end of week13:48
dhellmannsounds good13:48
ttxand come to yes/no call early next week, in time to submit13:48
ttxalright! that is all the urgent stuff I had :)13:48
dhellmannmy schedule this week is a bit of a mess because of the travel, esp. in my mornings, but we can do some async brainstorming13:49
ttxdhellmann: mine is a mess early next week. I'll take Monday and most of Tuesday off13:49
ttx(Bastille day)13:50
mesterydhellmann ttx: Here13:50
ttxmestery: hi!13:50
ttxmestery: about the ACL patch13:50
dhellmannttx: I'll be home some time tomorrow, but then drive to atlanta on thursday so I won't be online until a few hours later than usual13:50
mesteryttx: yes13:50
dhellmannI should be able to chat real-time early tomorrow if we need it13:50
ttxmestery: the issue there is the release model for those things in the stadium13:50
mesteryOk13:50
ttxmestery: the yaml says that they are released independently, without following the cycle at all13:51
mesteryttx: yes, correct13:51
ttxi.e. no stable branch, no "final" release etc13:51
mesteryI've seen some of them want stable branches already13:51
ttxthey can't have stable branches if they don't do a final cycle release though13:51
mesteryDoes "release:independent" mean NO stable branches, or that it just doesn't participate in stable branches?13:51
ttxthat is what stable branches are created *from*13:51
dhellmannmestery: it means "we don't keep up with what they do, buyer beware"13:51
mesteryInteresting13:52
mesterydhellmann: :)13:52
ttxso no cycle adherence, no stable branch13:52
mesteryOK, we'll need to talk on this13:52
mesteryBecause osme of them want stable branches13:52
ttxmestery: what would it be called ?13:52
ttxobviously not stable/kilo since it doesn't recignize kilo13:52
ttxstable/0.5.0 ?13:52
dhellmannwhy wouldn't they use the same stable names as everyone else?13:53
ttx(that is fine, but the stable maint team and the release team will likely prefer to ignore it then)13:53
ttxdhellmann: because they don't do a "end of cycle release"13:53
dhellmannthat name will actually test them against master, which is probably not what they want13:53
ttxso they choose to ignore the cycle completely13:53
dhellmannttx: right now they don't, but don't we want them to?13:54
mesteryFYI, on a call, going async13:54
dhellmannmestery: ack13:54
ttxdhellmann: they should want to, I agree. But apparently they don't ?13:54
ttxIt may be a misunderstanding of what cycle-with-intermediary means13:55
ttxbasically my point is... you can't have stable branches and ignore development cycles completely.13:56
dhellmannttx: ok, I think we agree. release:managed and release:independent are mutually exclusive, so they have to pick one of the other release models13:56
ttxand if you don't have stable branches and ignore development cycles, I'd rather not manage you13:56
dhellmannand I think based on our previous discussions of stable, we don't want branches using that name created outside of the control of the stable-maint team13:56
ttxdhellmann: well the new release:independent is. The old one could be combined with "release:at-6mo-cycle-end13:56
dhellmannso we could let them reuse the bug branches if they want to backport13:57
dhellmannttx: right, I'm thinking of the new one13:57
ttx(which again proves that the current one is unsuable :)13:57
ttxunusable*13:57
ttxdhellmann: how would bug branches be different from cutting random stable/X.Y.Z branches (like gnocchi does) ?13:58
dhellmannttx: branding13:58
dhellmannalso, technically, stable/x.y.z is tested against master because there are no other stable branches with the same name13:58
ttxoh, you mean we should disallow stable/X.Y.Z altogether13:59
dhellmannright13:59
dhellmanncall those something else13:59
dhellmann"stable" is a reserved name13:59
ttxhmm, we'd have to see how common that is13:59
dhellmannjust like we don't want ops and tc "tags" using the same name for different meanings...13:59
ttxI agree with you, I just fear that ship has sailed14:00
ttxespecially with stackforge imports that went wild with branch naming14:00
ttxwould we require a cleanup ?14:00
dhellmannah, I didn't realize it was that widespread14:01
ttxI guess we'd have to look at which projects did stable/random and ask them why they did it14:01
ttxif it's long-lived and common, find another name for it14:01
dhellmannyeah14:01
ttxif it's short-lived and exceptional, direct them to bug/x.y.z14:02
ttxI'd go for backports/2.3.414:02
ttxthat does not imply stability14:02
ttxor rules. Just the fact that it's a backport.14:03
ttxbecause you're right, calling them stable/x.y.z will break testing in unfun ways14:03
dhellmannso with the others, but the expectations are lower there14:04
dhellmannwe could add support for backports/ branches, but I didn't originally intend for bug/ branches to be short-lived so I'm also ok with loosening the restrictions we ended up applying14:05
ttxdhellmann: I thought bug branches would live just enough for one backport, tag, and then dissappear ?14:05
ttxanyway, that's a parallel discussion14:06
dhellmannttx: well, I didn't expect them to be deleted14:06
dhellmannyeah14:06
dhellmannI expected them to be lighter weight than stable, and to explicitly be tested against master (vs. the implicit thing we get when stable/foo doesn't match any other projects)14:07
ttxfor the neutron stadium, they have to pick between "independent, ad-hoc backport branches, tag yourself" and "cycle-with-intermediary, stable branches, tag by RelMgt team"14:07
ttxideally they would all pick the same model14:08
dhellmannyes, I think we should encourage (require?) the same model14:08
ttxboth options are definitely possible though.14:08
ttxMy understanding was that they cherished their independence and so I was surprised that they would ask us to tag. The benefit for those seems pretty limited14:09
dhellmannit sounds from mestery's email that he sees the second option as preferred14:09
ttxHe may have to get back to his team and discuss the two options.14:09
dhellmannright, I think they may need to have more discussion14:10
ttxJust wanted to check if we were on the same line before answering on that review14:10
ttxand we are14:10
dhellmannyes, I think so14:10
dhellmannfwiw, I also assumed the teams wanted the change, but I guess that's not a safe assumption14:11
dhellmannttx: the doc tools might be an example of a case where we have something release:managed, not on a cycle boundary, and without stable branches14:45
dhellmannttx: https://review.openstack.org/#/c/197297/114:45
ttxI gues sthe question becomes, why is it a snowflake14:57
dhellmannttx: it's not a production tool, so why would they need stable releases? maybe they do, for stable doc builds?15:11
mesteryttx dhellmann: I see the two options above, I'15:13
mesteryI'll present those to the team and see what people think15:13
mesterythanks for the counsel here!15:13
*** dims has quit IRC15:16
dhellmannmestery: ++, let us know if there are concerns either way15:18
mesterydhellmann: sure, thanks for that! I think it may make sense for these releases to be done by the neutron team instead of library-release, I'll consult and let you know.15:18
mesteryThanks for all the help!15:18
*** dims has joined #openstack-relmgr-office15:43
* dhellmann prepares for office hours17:01
*** david-lyle has quit IRC17:19
*** bnemec has joined #openstack-relmgr-office17:20
bnemecdhellmann: Howdy17:20
dhellmannbnemec: bonjour17:21
dhellmannbnemec: so, tripleo releases?17:22
bnemecdhellmann: Yeah, I think you released os-cloud-config a while back and said there was a missing permission in the launchpad project that made it not work right with the release scripts.17:22
bnemecI'm guessing all of the tripleo projects need that fixed.17:22
dhellmannchecking...17:23
dhellmannok, looking at https://launchpad.net/os-cloud-config I see the driver is SpamapS and the maintainer is "tripleo"17:23
dhellmannwe need to get the release team into the permissions somewhere, let me look at another project to see how we did that17:24
dhellmannfor os-brick, the "openstack administrators" group owns the "cinder drivers" team https://launchpad.net/~cinder-drivers17:25
dhellmannand cinder-drivers is listed as the drivers for os-brick17:25
dhellmannwith openstack administrators the maintainer17:25
dhellmannI'm not sure which of those gives us the right permissions17:25
dhellmannI suspect if we change the owner of tripleo (https://launchpad.net/~tripleo) to "openstack administrators" that would help, but might be insufficient17:26
bnemecThat might do it.  oslo.concurrency just has Oslo Drivers for both: https://launchpad.net/oslo.concurrency/17:26
dhellmannsince spamaps is still listed as the driver, and I think the driver has permissions to create milestones17:26
dhellmannyeah, so I think you want "tripleo" as both driver and maintainer for all of the projects, and "openstack administrators" as owner of "tripleo"17:27
bnemecdhellmann: Okay, I'll see about getting that set up.  Thanks.17:28
dhellmannbnemec: we should also add "Openstack release team" as a member of tripleo17:29
dhellmannbnemec: I think that's the real thing we need, but having the ownership set up right will make sure we can administer the team later17:29
bnemecYeah, I actually don't have administration permission, so that's the first thing I need to resolve. :-)17:30
dhellmannok :-)17:30
*** dims has quit IRC18:53
*** dims has joined #openstack-relmgr-office18:58
*** Rockyg has joined #openstack-relmgr-office19:06
*** dims has quit IRC19:48
*** david-lyle has joined #openstack-relmgr-office19:50
morganfainbergdhellmann: i think we need to release a new keystone auth (should now go to the keystoneauth1 package19:51
morganfainbergdhellmann: it should just be head and version should be 0.<next>19:52
morganfainberglmk if we have issues.19:52
dhellmannmorganfainberg: I'm headed into the tc meeting, so it's going to need to wait a bit19:53
morganfainbergAnytime today works19:53
morganfainbergJust ping me if we end up with any issues on publishing etf19:54
morganfainbergEtc*19:54
morganfainbergand/or when youre looking at it19:54
dhellmannmorganfainberg: let me look quickly...19:54
dhellmannmorganfainberg: http://paste.openstack.org/show/35291219:54
morganfainbergLgtm19:55
dhellmannso 0.3.0?19:55
dhellmannmorganfainberg: is anything using keystoneauth yet that's going to have issues with the namespace move?19:55
morganfainbergI think i have everything in order for publishing keystoneauth1 from there. If it fails we'll try after meetings to resolve19:55
morganfainbergNothing should use it yet19:55
morganfainbergIf they do, they were warned in big text in the rwadme and package info19:56
morganfainbergThis will break until we do 1.0.19:56
morganfainberg0.3 is good19:56
dhellmannok19:56
dhellmannmorganfainberg: tagged19:58
morganfainbergThanks. Ill watch it.19:59
morganfainbergIf it doesnt work as expected... Ill circle up with you later today/tomorrow19:59
morganfainbergAnd we can poke it with a stick. Or something19:59
dhellmannmorganfainberg: I'm going to be unavailable for a while this evening, but dims, lifeless, and ttx can all tag again if needed20:00
*** wshao has joined #openstack-relmgr-office20:00
morganfainbergdhellmann: ack20:00
lifeless\o/20:08
morganfainbergdhellmann: published successfully. Yay. Will bug lifeless and others as needed if other things crop up. Thnx again.20:08
nikhil_klifeless: I think cutting a release should be fine today given the patches may or may not be merged20:27
lifelessok, I'll cut a release after the tc meeting20:37
lifelessdhellmann: could I beg a walk-through of the full tooling for that? I want to be sure I follow your process20:38
dhellmannlifeless: for a library the release_postprocess.sh script does the whole thing, except actually sending the email (it writes the body to a file in relnotes)20:46
dhellmannlifeless: I'm going to have to move locations after the tc meeting (the place I'm working is closing) but I should be able to help you when I get back online shortly20:47
lifelesskk20:49
lifelessI'll read the code and give it a spin to see20:49
lifelessdoes it do the tag too ?20:49
lifeless[I'll find out :))]20:49
*** wshao has quit IRC21:03
*** dims has joined #openstack-relmgr-office21:13
*** wshao has joined #openstack-relmgr-office21:13
dhellmannlifeless: I'm back online if you want to go through it -- there's a little setup you have to do for the launchpad scripting credentials21:23
*** dims has quit IRC21:30
ttxdhellmann: the oslo.concurrency 1.8.1 release announcement doesn't mention "kilo" -- is that a bug or a feature ?21:34
dhellmannttx: that may have been due to how dims ran the release notes script, or it may have been a bug. I did fix a bug with the --stable flag in that script, let me see if it merged21:35
lifelessdhellmann: sec, arguing about client APIs and use of TLS or callbacks or more functional structures21:35
*** dims has joined #openstack-relmgr-office21:35
dhellmannttx: https://review.openstack.org/196712 is blocked on another review, I think21:35
*** dims has quit IRC21:35
*** Guest7393 has joined #openstack-relmgr-office21:35
dhellmannttx: yeah, it's at the end of a chain where you made a suggestion on the first patch and I didn't address it yet21:36
dhellmannlifeless: np21:36
ttxack21:43
dhellmannttx: do you want to merge those and let me fix that in a follow-up or was it a blocking comment?21:49
ttxdhellmann: looking21:50
ttxdhellmann: let's merge it now21:50
*** wshao has quit IRC21:51
openstackgerritMerged openstack-infra/release-tools: Close milestones for post-version releases  https://review.openstack.org/19513021:54
openstackgerritMerged openstack-infra/release-tools: Handle more errors when updating bugs  https://review.openstack.org/19524221:54
openstackgerritMerged openstack-infra/release-tools: Catch errors checking for zuul status  https://review.openstack.org/19531921:56
dhellmannlifeless: before you tag anything, we should wait for the rest of this patch series to land ^^21:57
Rockygdhellmann: Thierry had a great idea to put the Product WG as a project under the User Committee.  I'm going to abandon the original TC patch and create a new one for doing it that way21:58
dhellmannRockyg: sounds good21:58
RockygI've already started the conversation on the user-committee ML and Tom Fifeld has agreed to drive it there.21:58
RockygIt's probably easiest at this point to abandon the infra patch and resubmit as a new with this info, too.21:59
RockygProduct group did have one question/request.21:59
Rockygrather than openstack/openstack-user-stories, they hope we can just go for openstack/user-stories for the repo.22:00
RockygYour thoughts?22:00
openstackgerritMerged openstack-infra/release-tools: Fix --stable flag  https://review.openstack.org/19671222:01
dhellmannlifeless: ok, you should be able to refresh your release-tools sandbox and get a sane version of the script22:02
Rockygdhellmann: ^^ oh, and the name changed from usecases to user-stories22:02
dhellmannRockyg: do we expect to have more than one group trying to write user stories?22:02
dhellmannwith the specs we have a prefix on the name to indicate the scope22:03
dhellmannapplying that here seems reasonable, if we might have more than one repo with them22:03
*** wshao has joined #openstack-relmgr-office22:05
RockygSo, there are other WGs that are generating user stories.  But the Product_WG wants to collect the cross wg stories.  The directory structure and focus would be a bit different.  We would link to the vertical's user stories22:05
RockygOr so the thinking goes. ;-)22:05
Rockygbut, if the plans don't pan out, we could subdir the stories and up-publish to a single point even so.22:07
RockygI find that one of the hardest parts of starting a repo is deciding on the structure, and most people don't understand the difficulties until they try to use what they have "designed".  Which is why source code is relatively easy, since it's a solved problem.22:08
dhellmannRockyg: if you think there will be others, then I would keep the "openstack" prefix to indicate its cross-project nature22:11
dhellmannlifeless: did you still want to do that run through? it's approaching dinner time here, so I'll be dropping off in a bit22:12
Rockygdhellmann: lemme check how telco is doing it....22:14
lifelessdhellmann: yes please22:15
lifelessdhellmann: I'm ready now22:15
lifelessdhellmann: updating ma sandbox22:15
dhellmannlifeless: cool, so as I said your main entry point is that release_postversion.sh script22:15
dhellmannit does all of the tagging and launchpad magic22:15
lifelessnikhil_k: what version # do you want ?22:16
dhellmannif you're not already set up to run scripts for launchpad, the first time you run that it will set up the credentials for you22:16
dhellmannI have, at times in the past, had trouble with lynx getting those credentials properly, but it worked eventually so I was able to run the scripts on my dev vm rather than directly on my laptop22:17
dhellmannand you obviously need gpg keys for the signature for the new tag22:17
dhellmannyou'll need space locally to check out the git repo to make that tag, but that shouldn't be an issue for most of the projects22:18
dhellmannlifeless: which project are you tagging?22:19
lifelessglance_store22:19
lifelessthere are non-bugfix changes22:19
lifelessso I'm thinking 0.7.022:19
dhellmannok, the list_unreleased_changes.sh script is useful for finding the pending changes22:19
dhellmannyeah, that version # makes sense22:20
*** wshao has quit IRC22:20
lifelessok, no reply from nikil or sigmavirus22:24
lifelessshould I abort?22:24
dhellmannlifeless: I would definitely wait until someone from that team is around and active so they can deal with fallout from the release22:24
lifelessack22:25
lifelessthough, constraints. yay.22:25
lifelessanyhow22:25
dhellmannI like to get them to sign off on the list of changes, too, so they're not surprised with what's going to happen22:25
dhellmannthat part will be explicit when we get the releases repo up and going22:25
lifelessI'm expecting to run ./release_postversion.sh liberty 0.7.0 glance-store22:25
lifeless?22:26
dhellmannyou need a sha in there22:26
lifelessohh right22:26
lifelessHEAD22:26
lifelessbut other than that looks ok?22:26
dhellmannyes, that's correct22:26
dhellmannI've started using the actual shas from the output of list_unreleased_changes.sh to be pedantic about what we agreed I should tag and what was actually tagged, but for a slow moving repo that's not as important22:26
*** Rockyg has quit IRC22:57
*** sigmavirus24 has joined #openstack-relmgr-office23:55
sigmavirus24Sorry about that. Was cooking & eating dinner. A release of glance_store isn't really a priority at the moment. It should be a problem but it will definitely be less confusing if all of the drivers work on Python 3 instead of "all but 2" working23:56
lifelessshouldn't or should ?23:57
sigmavirus24I'm hoping we can get some more cores to look at the last two patches from haypo23:57
sigmavirus24*shouldn't23:57
sigmavirus24Sorry23:57
lifelessso23:57
lifelessits like this. I can hit enter on the command line I have here23:57
lifelessand we do it23:58
lifelessor I can not :)23:58
lifelessthe constraints are - if it blows up, we fix it23:58
lifelessat least until bed - so if you're going to be aroundish for say 90m23:58
lifelessthen I think we're pretty good to go23:58
sigmavirus24Let me look at g-r quickly for the different branches23:59
thingeelifeless, dhellmann looking back at the instructions here http://lists.openstack.org/pipermail/openstack-dev/2015-June/066346.html it doesn't mention where I request tags, but I would like to release 1.3.0 of python-cinderclient ed2b133d4e5ac91c7a5719f53e666e870f9fd54623:59
lifelessthingee: here23:59
lifelessthingee: ok23:59

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