14:00:53 #startmeeting releaseteam 14:00:54 Meeting started Fri Nov 4 14:00:53 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:57 The meeting name has been set to 'releaseteam' 14:01:07 courtesy ping for dhellmann, dims, fungi, stevemar 14:01:51 Welcome back from Barcelona! This is week R-16, our agenda on the etherpad as usual 14:02:07 #link https://etherpad.openstack.org/p/ocata-relmgt-tracking 14:02:16 o/ 14:02:28 dhellmann should join us really soon now 14:02:35 still has that new-cycle smell 14:02:57 #topic move (some) tags from governance to releases 14:03:41 We have a plan to move some of the release mechanics tags (which are really not a governance thing) out of the governance repository 14:04:07 You can see details of that plan on https://etherpad.openstack.org/p/ocata-relmgt-plan 14:04:24 line 137+ 14:04:58 The idea would be to move type:* and release:* tags out of the governance repo 14:05:35 and the lack of comments implies it's in no way contentious 14:05:37 We would duplicate the deliverable structure between both 14:06:06 any reason to duplicate the structure rather than just having a flat list of deliverables? 14:06:15 Now we are wondering who we need to engage with early on, and who would get broken by this 14:06:34 ttx : which repo would be the authoritative source? (which sync's to which) 14:06:53 fungi: I think we still need the team-deliverable relationship on the release side 14:07:13 but when I say "duplicate" it's actually not a centralized yaml file 14:07:29 On one side you would have the governance projects.yaml file 14:07:33 any reason not to just let the deliverable to team mapping stay in governance, and just keep the deliverables as a flat list in releases though? 14:07:50 that reduces the risk of having them get out of sync 14:08:06 On the other a bunch of cycle/deliverable.yaml files in the releases repo 14:08:32 fungi: I think that is the plan 14:09:11 we would just store the release model and type of deliverable in the openstack/releases yaml files instead of the governance projects.yaml 14:09:17 (which would stay authoritative) 14:09:27 probably a silly question, as a new release liaison, how familiar should I be with all of this/ 14:09:36 oh, got it. when you said duplicate the structure i thought you mean including grouping deliverables by team in releases, which seems like a lookup we could do against governance as a single source of authority for that 14:09:59 sigmavirus: It should not change much for liaisons. Of all things it might make changing deliverables content and types easier 14:10:16 Now, what/who will that break 14:10:33 The project navigator uses type: to filter what it should display 14:10:41 (only shows type:service) 14:10:41 sigmavirus: basically if you plan to add a deliverable or change the release model you'll now need to also edit a file in the releases repo adding an entry to the current cycle's yaml file 14:11:00 It also displays the release model, although I'm not sure why 14:11:09 ttx: likely "because it can" 14:11:15 yes 14:11:43 We might want to generate some compound mega-yaml file for them to consume rather than force them to walk down the openstack/releases directory tree 14:11:58 sigmavirus : if you keep up with the rst files in https://github.com/openstack/releases/ that should be good enough i think 14:12:15 we could easily postprocess all of this in a ci job and publish it as structured data or even provide a lightweight lookup api 14:12:57 if there's a concern that they really can't retrieve two files and do the equivalent of a join query 14:13:04 Any other idea of what might get broken by this ? 14:13:31 dims: thanks :) 14:13:42 any of the scripts used for validating the tags may be affected? 14:14:04 They should not really look into type:* or release:* 14:14:05 none of the automation i maintain cares about deliverable types or release models, so none on the infra side afaik (except for jobs the release team is caring for that is) 14:14:11 right 14:14:31 fungi: thank you for explaining that in terms I can understand ;) 14:14:33 OK, let's move on 14:14:51 #topic moving release date to Feb 22 14:15:01 Also known as "because Ocata wasn't too short already" 14:15:23 This is done to facilitate downstream post-release work 14:15:40 bar napkin math says ot's still only a 1% shrinkage in the number of business days for the cycle 14:15:50 Releasing on Thursdays kind of pushed them into Saturdays work more often than not 14:16:25 I checked with the PR team at the Foundation, they have no particular relationship with Thursdays 14:16:25 +1 to do this 14:16:46 Actually Wednesdays might even be better for them (for the same downstream work reasons) 14:18:01 OK, so this looks good, I expect dhellmann to close it when he has a chance 14:18:11 next topic... 14:18:19 #topic changing the library freeze date 14:18:41 In BCN we discussed moving the non-client lib out 1 week to match the 3rd milestone on R-4 14:19:15 that said, dhellmann noted that moving to R-4 would mean that we do not freeze the libraries before the requirements list, which means we might end up adding features to a library but not having them be consumable because we can't update the lower bounds of a requirement 14:20:01 So should we stick to 2 deadlines ? Or move all libraries up to R-3? 14:20:43 ttx did we get any preference from tonyb ? 14:20:48 dims: do you remember why we considered doing that ? 14:22:25 I'm missing a bit of info there. Let's wait for dhellmann 14:22:25 ttx : guessing we saw folks needing a library update to fix a problem late in their 3rd milestone 14:23:35 We already have client lib freeze and requirements freeze on the same date, so I don't understand why that would make features any more less consumable 14:24:10 Let's move on ang get back to that later if dhellmann joins us 14:24:16 ack 14:24:20 #topic Moving release meeting one UTC hour later starting next week (keep same US time) 14:24:56 Since teh US joins Europe out of DST next week, we can adjust our team meeting time to place it at the same local day hour 14:25:25 +1 ttx 14:25:27 I'm -0 on that as a central US person 14:25:39 I'm +0 on that since I'm a EU person 14:25:58 Mostly because work weird hours as it is, so an hour earlier/later doesn't affect me 14:26:15 Basically without the change, the meeting would be at 9am Eastern instead of 10am eastern if we don't change anything 14:26:28 * dhellmann arrives late 14:26:32 here he is 14:26:34 yeah, maybe people on the west coast of the usa care about this 14:26:36 #chair dhellmann 14:26:37 Current chairs: dhellmann ttx 14:27:09 dhellmann: currently discussing moving the meeting hour to 15:00utc starting next week 14:27:09 on the other hand, there are no release team members in western north america at the moment 14:27:33 iirc we've moved it in the past, haven't we? 14:27:42 I think so yes 14:27:48 I'll propose the change 14:27:58 yeah, let's move it if the slot is open 14:28:01 #action ttx to propose meeting time change for release meeting winter time 14:28:03 i'm not personally keen on meetings that change utc time because it's atypical in our community, but it's not my meeting ;) 14:28:25 :) 14:28:38 #topic changing the library freeze date 14:28:43 back to previous topic 14:29:26 I looked at what would happen if we moved the dates as we said in BCN 14:29:27 dhellmann: I was wondering why moving non-client lib freeze at the same time as client-lib freeze would be a problem wrt. requirements 14:29:37 well, the requirements freeze would be the same time then 14:29:49 if it is a problem, we already have it for client lib, then 14:30:14 the server projects are less likely to be consumers of features added to the client libs 14:30:26 at least that's my assumption 14:31:26 since I proposed this change, and now I'm undecided, is anyone else strongly in favor of one course or the other? 14:31:49 dhellmann : keep what we have :) 14:32:10 let's keep 14:32:11 I think I'm leaning in that direction now, too 14:32:12 in doubt 14:32:17 ok, I think that's agreement 14:32:25 #agreed we will not try to change the library freeze dates for ocata 14:32:35 #link https://review.openstack.org/393800 <-- meeting time change 14:33:00 ok, next topic 14:33:04 #topic Freezing Monasca releases until the license is sorted out 14:33:22 #link http://lists.openstack.org/pipermail/openstack-dev/2016-November/106687.html 14:33:28 the email thread pointed to some confusion about what license is actually being used 14:33:44 I suspect it's a leftover file but better make sure of that, and quick 14:33:47 rather than making things worse, it seemed like a good idea to freeze any releases until they sort it out 14:33:52 right, I assume the same 14:33:53 agreed 14:34:06 in fact, maybe someone could go ahead and propose the patch to update the file 14:34:12 which means, given how present Monasca folks are on IRC, reaching out aggressively to them 14:34:29 review might be a good way to get them to pay attention, yes 14:34:29 i'd _love_ it if someone from monasca would respond there. do they read the -dev ml? 14:34:37 fungi: that would be ideal 14:34:38 fungi : their participation is spotty 14:34:43 right 14:35:07 seems like at least the ptl would be paying attention to things tagged [monasca] on the ml 14:35:10 #agreed freeze monasca releases until the license situation is straightened out 14:35:11 in the meantime, I agree we shouold not release anything there until they clarified 14:35:11 oslo.messaging kafka is stuck on their feedback as well 14:35:39 dims : that's good to know 14:35:54 Great example of why sharing the same communication/principles/culture is essential 14:35:54 we've had trouble reaching that team a few times now. it might be time to bring it to the tc's attention. 14:36:06 because in those cases it hurts everyone 14:36:29 that said, it is only the week after summit so I was going to give them until next week before having a larger response 14:36:53 To be specific they had an action item to get back to us on g-r being switched to newer python-kafka versions 14:37:36 also, i'll admit, the place to raise that license question is _probably_ monasca's bug tracker 14:37:39 If we don't have any response by next week TC meeting I might raise the topic of minimal participation to communication mediums as a reason for not be official anymore 14:37:46 i'll copy cuhck's request to a bug report 14:37:51 fungi : good point, a bug would be nice 14:37:52 fungi: thx 14:38:02 ttx: ++ 14:38:15 and i'll follow up to the ml thread with the url 14:38:22 thanks 14:38:27 I think that covers this topic? 14:38:37 yes 14:38:54 #topic New driverfixes branch type 14:39:13 #link https://review.openstack.org/#/c/393451/ 14:39:48 I just wanted folks on the release team to be aware that this is a new branch type. smcginnis and I picked the name yesterday. So far only Cinder uses it, but if other teams want to do something similar we'd want the same name type 14:40:02 Still not a big fan of having untested branches in our official repos, but meh 14:40:18 basically, this is a branch created from stable/$series at a point close to when the stable branch goes dormant, to give vendors a central place to collaborate on long-lived driver support 14:40:26 untested/$series would make it clearer 14:41:01 yeah, we talked about untested/driverfixes/$series as the name but that felt different from the other patterns we have with just 2 levels in the name 14:41:24 and I think the idea is that only changes to drivers would be allowed in the branch, so we wanted to highlight that 14:41:33 also discourages them to collaborate on stable branches a bit 14:41:34 ttx, dhellmann: Still time to change it I suppose. untested/mitaka would be OK with me, though I do like the descriptive name of driverfixes. 14:41:40 dhellmann: +1 14:41:52 smcginnis: yeah, untested only partially captures the idea 14:42:12 ttx: I thought the opposite -- if they get used to collaborating on these branches, maybe they'll be encouraged to also work on the stable branches before the driverfixes branch is created 14:42:36 who has +2 on driverfixes/* 14:42:38 ? 14:42:44 good question. smcginnis? 14:42:46 some specific group ? 14:42:49 ttx: Core team only for now. 14:42:59 So for this instance, cinder-core 14:43:15 so you'll be doing minimal reviews? or setting up another group to manage the branch? 14:43:41 And to be clear, this is only for branches once they go to security-supported mode, so I don't expect it to decrease stable branch involvement. 14:43:51 right, that was my understanding 14:43:54 dhellmann: Yes, minimal reviews only. 14:44:00 post-eol-driver-fixes/* would be a mouthful indeed 14:44:09 ttx: ;) 14:44:30 ttx: On the other hand, very clearly named. 14:44:31 when it's all set up, it would be great to have this written up in the project team guide 14:44:32 set the pattern, explain the expectations, etc. 14:44:40 dhellmann: +1 14:44:48 smcginnis : is that on your todo list? 14:44:53 I guess I don't want people to think that this is the place where driver fixes go. It's the place where driver fixes go after eol, and those are untested 14:45:06 Once all the puzzle pieces are in place I plan on writing up a Cinder devref and ML post explaining it. 14:45:17 Hopefully we can adapt that for the project team guide. 14:45:18 I guess that should be made clear with the branch name though 14:45:27 smcginnis : ++ 14:45:43 i.e. driverfixes/liberty when stable/liberty is dead, should make it pretty clear. 14:45:54 i got the impression it wasn't _just_ after eol 14:45:55 ttx: That's my hope. 14:46:07 but also fixes which wouldn't be approved by the stable branch maintainers 14:46:09 security mode and oel 14:46:16 fungi: unstable/liberty :) 14:46:18 yeah, it's not quite eol, is it? it's when it goes into security mode, which is a bit before eol 14:46:25 ttx: That was my suggestion! :) 14:46:45 eol as far as the driver maintainers go. :] 14:46:53 sandbox/liberty 14:47:03 And key word in fungi's statement: fixes 14:47:10 No backporting new driver features. 14:47:22 right, it's limited to fixing issues in the drivers 14:47:29 oh well, worst case scenario it's not hard to rename branches 14:47:54 it's a new thing. we still have folks who don't understand what stable/ means, too. 14:47:58 And if this turns into an unforeseen disaster, I'm OK saying we tried our best and call it a failure. 14:47:59 The important part being to standardize on a common prefix 14:48:04 But I really hope that doesn't happen. 14:48:12 smcginnis : so a retrospective at the ptg? 14:48:15 ttx: right 14:48:17 i have suspicions this won't actually help the situation in any way, but it's worth a try and if the experiment fails it's not like you have to keep doing it 14:48:35 dhellmann: Sure, that can't hurt. Could also be a good way to educate on it's use/existence. 14:48:47 smcginnis : yep 14:48:50 +2 14:48:58 fungi: Package maintainers have been asking for this for a while. 14:49:08 so we're all ok with the name as it is, at least for now? 14:49:14 +2 14:49:24 cool 14:49:38 i mean, we heard similar stories about why we should keep stable branches around for longer because distros would be submitting patches there, but most of the time it's only upstream devs submitting patches so once they stop caring the distro package maintainers just do their backporting in isolation anyway 14:50:13 this has been the schizophrenic definition of our stable branches for as long as i've been involved in openstack 14:50:24 #agreed let's give driverfixes/* a try 14:50:34 #topic open discussion 14:50:43 fungi: True. But that's why I've wanted to make it clear this is not in any way considered "stable". :) 14:50:47 dhellmann: maybe read the first part of the meeting and let us know what you think 14:50:49 yes, I think this was a compromise between expanding stable support and forcing vendors to maintain forks, which then result in the inability to mix drivers from different providers in a deployment 14:50:56 belated +2 on driverfixes/* 14:50:59 ttx, I was just going to ask if there was anything else you deferred 14:51:15 * smcginnis goes back to trying to figure layout.yaml 14:51:20 not really but you migth want to chime in on some 14:51:39 especially the first one 14:52:15 the deliverable file changes? 14:52:20 yes 14:52:33 and who will be affected / we should talk to 14:52:44 I like the idea of building a single yaml file with the deliverable tags to make it easier for someone to consume the results 14:53:46 that would solve the navigator issue, I guess 14:53:59 and I was specifically trying to find out who to talk to on the team that builds that 14:54:12 is that outsourced from the foundation? 14:55:02 dhellmann: that would be Jimmy McArthur on staff 14:55:18 ok, maybe I can get his contact info from you separately then 14:55:20 he coordinates who ends up doing it 14:55:30 I can handle the comms there 14:55:53 once we have a clear detailed plan and some buy-in from the TC, I can engage 14:55:57 ok. my plan for now is to start by putting the data we need in the releases repo, and then stop pulling data from the governance repo at all 14:56:13 but I don't expect there to be any problem, especially if we generate that single file 14:56:15 then we can deal with publishing any extra data files for them to make their lives easier 14:56:26 they already get data from several sources to aggregate them 14:56:27 it would be 1 per series 14:56:36 since the whole point is this stuff changes over time 14:57:20 but I can just plan on building out the single yaml file if we expect that to be the thing they request 14:57:45 time is almost up, is there anything else? 14:58:00 and i guess we only ever publish for the current cycle, since there aren't per-cycle copies of our governance reference data 14:58:41 fungi : that's a good point 14:59:21 alright, I think that's it for today 14:59:30 apologies again for being late, and thanks ttx for starting the meeting without me 14:59:37 np 14:59:43 #endmeeting