14:01:41 <dhellmann> #startmeeting releaseteam
14:01:41 <dhellmann> courtesy ping: ttx, dims, lifeless, tonyb, stevemar
14:01:41 <dhellmann> If you would like for me to add you to the courtesy ping please say so
14:01:42 <openstack> Meeting started Fri May 13 14:01:41 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:45 <openstack> The meeting name has been set to 'releaseteam'
14:01:52 <IgorYozhikov> o/
14:02:05 <toabctl> hi
14:02:11 <dirk> Hi
14:02:18 <number80> o/
14:02:31 <dhellmann> hi, everyone
14:03:32 <dhellmann> our agenda is under week R-21 on https://etherpad.openstack.org/p/newton-relmgt-tracking
14:03:38 <dims> o/
14:04:06 <dhellmann> #topic Prioritizing tasks for the cycle
14:04:06 <dhellmann> #link https://etherpad.openstack.org/p/newton-relmgt-plan
14:04:15 <dhellmann> I've started adding N[123] notes before TODO items there. I'd like to review them to make sure I haven't missed anything or placed anything too late in the cycle, and then attach names to the N1 items at least.
14:05:00 <dhellmann> let's start by looking at the "communication/governance changes" section
14:05:03 <ttx> o/
14:05:39 <dhellmann> I went ahead and put my name next to the releases.o.o site changes since I've already started those
14:06:53 <dhellmann> we have 2 tasks for reviewing existing release tags
14:07:18 <dhellmann> we didn't spend much time discussing horizon plugins at the summit, did we? should we start ensuring those have type:library?
14:07:21 <ttx> I shall do the ACL dance spec for N1
14:07:55 <ttx> dhellmann: alternatively we could create a specific type for them
14:08:05 <ttx> or for them + other plugins
14:08:21 <dirk> What's the flag for neutron plugins?
14:08:33 <dirk> Same concept than horizon right?
14:08:42 <zigo> o/
14:08:45 <dhellmann> do you think we need a separate plugin type? how would we treat those differently from non-plugin libraries?
14:08:45 <ttx> I think we actively recommended *not* to use library for horizon plugin modules
14:08:59 <dhellmann> hmm, I didn't remember that
14:09:15 <ttx> so that they all appear in the same section
14:09:17 * ttx checks
14:09:31 <dims> dhellmann : i can tackle - "TODO review projects with cycle-based models to ensure they are all set up for relmgt to manage their releases" if we can come up with things i have to check for each project
14:09:41 <ttx> dhellmann: most are in "others" right now
14:09:54 <dhellmann> dims : ok. I think that's just a review of their acls in project-config to make sure we have tagging rights
14:10:04 <ttx> dhellmann: only senlin-dashboard is still type:library
14:10:06 <dhellmann> ttx: that generally means they have no type tag at all
14:10:35 <ttx> right, but in mitaka so that they would appear in the same section I actively recommended that they did not pick typoe:library in reviews
14:10:50 <ttx> That's definitely a stop-gap until we figure out how to classify them
14:11:01 <dhellmann> so maybe it makes sense to have a type:plugin or type:extension or something to handle those cases? would we want ui-plugin and networking-plugin or is one type enough?
14:11:02 <ttx> personally I think it would be great to list them under a specific category
14:11:15 <dims> dhellmann : added my name next to it
14:11:19 <ttx> rather than lose them in the middle of libraries as if any code could import them
14:11:28 <dhellmann> yeah, I'm starting to see the value of that. I was worried about the extra logic in the tools to handle things that are like libraries
14:11:33 <dhellmann> ttx: makes sense
14:11:38 <dhellmann> dims: thanks
14:12:07 <ttx> So we could either have a type:other (and enforce picking of type) or have type:plugin (or other name) and keep the "others" to represent oddities that do not pick type
14:12:54 <ttx> Question is more, should we have a specific type for horizon plugins, or a specific type for all sorts of plugins (like devstack, horizon...)
14:13:00 <dhellmann> yeah
14:13:28 <dhellmann> having all of the UI plugins and network plugins lumped together may seem odd, but at the same time do we want a zillion different types that people have to understand?
14:13:35 <ttx> part of a larger discussion I guess
14:13:44 <dhellmann> yeah, ok, let's table that for now and keep going
14:13:57 <ttx> My main goal being to keep "libraries" for things that could be imported by any code, at least in theory
14:13:58 <dhellmann> sorry, the american version of "table" - set aside :-)
14:14:13 <dhellmann> yep, that's a good definition
14:14:16 <ttx> rather than code extensions that happen to leave in separate repos
14:15:11 <ttx> agreed for N1 on that
14:15:40 <ttx> and we should both work on that
14:15:47 <dhellmann> I'll give that more thought and maybe we can have a separate conversation later
14:15:53 <ttx> ack
14:16:08 <dhellmann> ok, "final release process improvements"
14:16:34 <dhellmann> the only N1 item I found there was to identify freeze periods like before major holidays
14:16:46 <ttx> I took the wiki cleanup action since I'm wiki admin I probably have rights there
14:16:48 <dhellmann> there are fewer extended holidays in this part of the year
14:16:53 <dhellmann> oh good, thanks
14:17:30 <dhellmann> I came up with 4th of july, there may be others, but all of them seem to just be 1 day so I'm not sure we need to pre-declare a freeze like we would around new year's and winter holidays
14:17:36 <dhellmann> thoughts?
14:18:26 <dhellmann> it might be enough to just mention anticipated delays in the countdown emails
14:18:28 <dims> dhellmann : am ok with not pre-declaring a freeze
14:18:33 <dims> right
14:18:34 <ttx> yeah, feels like a bit too much
14:18:49 <ttx> if only because holidays are different everywhere and all
14:18:57 <dhellmann> right
14:19:23 <dhellmann> although I think the point is really to say when we know most of the folks with permission to release aren't going to be around to do it
14:19:45 <dhellmann> the rest of this section can wait until later in the cycle. we won't want to wait to start, but we don't have N1 as a deadline, I think
14:20:19 <dhellmann> shall we move on to "reno feature development"?
14:21:09 <dhellmann> the main thing there for N1 is to figure out how badly merging tags from stable branches into master confuses reno and where it puts the release notes
14:21:16 <dhellmann> fungi showed us how that works at the summit
14:21:31 <dhellmann> we just need to experiment and possibly fix the problem
14:21:31 <ttx> ack
14:21:56 <dhellmann> I think the releases site work is more important, so this is likely to slip past N1 if it stays on my plate
14:22:56 <dhellmann> ok, let's leave that unassigned for now and we can pick it up when we have time
14:23:06 <ttx> yeah, might pick it up but unlikely
14:23:23 <ttx> adding as tentative to my todo
14:23:34 <dhellmann> yeah, I expect this is something I'll have to do. We need to get some other folks familiar with the reno code, though, so it would be good to have someone else try looking at it.
14:23:48 <dhellmann> moving on to "Automation for releases when changes merge in openstack/releases"
14:24:25 <ttx> yeah, that's why I'm /considering/ doing it... I just know that that's the sort of thing that will continually fall off my list
14:24:28 <fungi> i'm happy to collaborate with whoever looks into the tag merging implications on reno
14:24:35 <fungi> just give me a heads up
14:24:38 <ttx> ok
14:24:40 <dhellmann> fungi : thanks!
14:24:44 * ttx needs some code exercise
14:24:58 <ttx> too many frustrating social issues
14:25:08 <dhellmann> indeed
14:25:12 <fungi> all social issues are frustrating
14:25:23 <fungi> or maybe i'm just antisocial
14:25:23 <dhellmann> maybe I can twist stevemar's arm to looking at it, he expressed some interest in helping with release tools
14:25:53 <dhellmann> fungi , while you're here, we were about to talk priorities for automation tooling
14:26:16 <fungi> dhellmann: so on the automation front, how did those script updates to incorporate git notes into the tag message work out?
14:26:17 <dhellmann> I'm not expecting any infra changes to support that work to be done by N1. Maybe N2?
14:26:21 <fungi> i haven't looked for an example yet
14:26:41 <dhellmann> fungi : I have that review up, and it's working great when I use it locally. All of the releases in the past week or so have the metadata in the tag message
14:26:46 <fungi> dhellmann: i'm wanting to pick it up in the next week or so, but yeah shooting for n2 makes sense
14:26:53 <dhellmann> thank you for the tip, that worked out really well
14:27:09 * fungi thought that change got approved last week
14:27:21 * fungi has terrible memory
14:27:38 <dhellmann> oh, maybe it did, I have a bunch of other patches up for review
14:27:46 <dhellmann> yeah, you're right, that's merged now
14:28:06 <dhellmann> it was approved last week, but depended on another patch that didn't so I rebased and let it merge
14:28:14 <fungi> cool, i'll go look at a recent oslo release
14:29:00 <dhellmann> the data's just in the tag message for now, I didn't add anything to the contents of the release (I hadn't thought of that until just now)
14:29:05 <fungi> #link http://git.openstack.org/cgit/openstack/oslo.context/tag/?h=2.3.0
14:29:11 <fungi> that is marvellous fancy
14:29:28 <dhellmann> ttx: did you spot anything in this section that we need for N1 that I tagged otherwise, or didn't tag at all?
14:30:24 <ttx> WOuld be good to work on requirements spinoff, but without PTL to initial-lead it's hard
14:30:47 <dhellmann> dims is starting to put some stuff together for that, I was going to ask for an update after we're done with priorities
14:30:49 <ttx> Maybe we could convince dims to initial-PTL it
14:31:01 <dhellmann> sssh, I was going to be more subtle!
14:31:01 <fungi> or just treat dims as de facto ptl ;)
14:31:04 * ttx whistles innocently
14:31:04 <dhellmann> right
14:31:12 * dhellmann looks the other way
14:31:17 <dims> ttx : yes, that's an option :) but i am trying hard to bring up someone else
14:31:19 <ttx> he is not here right
14:31:23 <ttx> oops
14:31:41 <dhellmann> foiled again by irc mention notifications
14:31:51 <ttx> those should be outlawed
14:32:00 <dims> :)
14:32:53 <dhellmann> for the release manager's manual, I expect that to be a larger ongoing project and won't really have time to even start it before n1
14:32:55 <ttx> dhellmann: I think we can revisit extra N1 goals if we end the list before then
14:33:07 <dhellmann> we might make a decision about where we want to publish it by n1
14:33:25 <dhellmann> yeah, I think this list is long enough and I don't think we have anything else that qualifies as must have for n1
14:33:29 <ttx> Oh, another thing we might want to do in N1
14:33:36 <ttx> actually more "asap"
14:33:48 <ttx> is how screwed or not screwed we would be by the addition of Go
14:33:57 <dhellmann> yeah, good point
14:34:12 <ttx> we might want to dedicate a brainstorm discussion early next week to that
14:34:15 <dhellmann> we'll have to look at our tools and see how many of them do things like run "python setup.py --name"
14:34:23 <dhellmann> right
14:34:30 <ttx> I'm off Monday though
14:34:40 <dhellmann> maybe we can do that early tuesday, before the tc meeting
14:34:46 <dhellmann> or later today, if folks are around
14:35:00 <fungi> however, wouldn't be the first time we've put setup.py/setup.cfg and pbr into non-python projects if we hacked around it the ugly wa
14:35:02 <fungi> y
14:35:02 <ttx> Early early Tuesday then, I enter a meeting tunnel starting 14:30utc
14:35:14 <dhellmann> ok
14:35:15 <dims> ttx : that sounds good
14:35:32 <ttx> so... 1300utc maybe
14:35:39 <dhellmann> fungi : good point. it might be "nicer" for us to create a tool "get_name_for_project" that we can use in lots of our scripts instead
14:35:54 <ttx> dhellmann: can you make that time ?
14:36:11 <dhellmann> looking
14:36:40 <dhellmann> ttx: 1300 on Tuesday?
14:36:43 <ttx> yes
14:36:53 <dhellmann> yes, I can do that
14:36:59 <dhellmann> dims, fungi : can either of you make it then?
14:37:05 <ttx> gives us some time Monday to update knowledge to state of the art of Golang releasing
14:37:11 <dhellmann> we don't want a huge crowd, but a few more minds would help
14:37:21 <ttx> I guess that still would quality as "holiday"
14:37:30 <dims> 1300UTC dhellmann ? what time in our TZ?
14:37:41 <dhellmann> dims : I make that 9:00 AM
14:37:44 <ttx> that would be 9am
14:37:45 <fungi> i can do 1300 utc tuesday, sure
14:37:53 <dims> yep. i can
14:38:12 <dhellmann> cool, let's plan on that in #openstack-release
14:38:14 <ttx> ok, cool, so that at least we can mention an estimate at that TC meeting if needed
14:38:29 <fungi> that's specifically for go-ification brainstorming, correct?
14:38:32 <ttx> although that TC meeting is supposedly about technical bnefits rather than cost
14:38:38 <ttx> fungi: yep
14:38:43 <fungi> perfect
14:38:52 <ttx> if cost is crazy (should not be) better raise it early
14:39:31 <dhellmann> good, thanks for raising that ttx
14:39:44 <dhellmann> #topic bootstrapping the requirements team
14:39:47 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/094218.html
14:39:47 <dhellmann> dims, you've started some work on this, is there anything to report or do you need us to take any action?
14:40:45 <dhellmann> joking from earlier aside, I appreciate you picking this up
14:41:27 <dims> dhellmann : no worries at all. so a few people are actively reviewing. me and Dirk are doing a joint review session every day.
14:41:42 <dhellmann> very nice
14:41:58 <ttx> I more than appreciate. One of those things I historically run but did a bad job giving a second life lately
14:42:00 <dims> we have cleared a bunch of backlog, we want to simplify the add/delete from projects.txt as a trivial thing and not wait for +2 from 2 cores
14:42:00 <fungi> yeah, dirk has been very active, i've noticed
14:42:01 <dhellmann> I have noticed a few people giving some good comments when I reviewed this week
14:42:24 <dirk> my main concern right now is that I can provide input from the packaging side but I don't know all about the complex interactions with the gate and the release schedule yet
14:42:27 <dhellmann> dims : when that validation patch I posted yesterday lands I'd support that policy change
14:42:45 <dims> harder problem is "when to approve bot proposed updates" which needs better test matrix
14:42:46 <dhellmann> dirk : ok, we can work on education about the schedule
14:42:47 <fungi> on a related note, we removed having gerritbot echo requirements changes in #openstack-infra (i think that's merged now)
14:42:51 <dirk> my feel is that we need to staff up somehow on both sides (distro input + still need a good liason from release team)
14:42:53 <dims> dhellmann : ack
14:42:58 <dhellmann> dirk : basically we don't want to change a bunch of requirements during peak deadline periods
14:43:09 <dirk> fungi: did it change to openstack-requirements? it should
14:43:26 <dhellmann> fungi : did my script for submitting constraints trigger that change? :-)
14:43:32 <dims> fungi : dhellmann : the canaries we are using now are here - https://review.openstack.org/#/q/status:open+branch:master+topic:dims/test/constraints
14:43:44 <dirk> dims: yeah, but that when-is-it-safe-to-approve just needs a much better automation
14:43:48 <dims> fungi : dhellmann : i have a cron job that freshes that
14:43:57 <fungi> dirk: gerritbot can echo in multiple channels, but if it's not echoing in #openstack-requirements (that's a very new channel, right?) then it's an easy change to add that
14:44:11 <dirk> fungi: let me see if I can post a review for that
14:44:16 <dhellmann> dims : nice. I hope we can make that more official this cycle.
14:44:17 <dims> fungi : i have a review for the bots
14:44:30 <dims> fungi : dirk : https://review.openstack.org/#/c/315543/
14:44:48 <dirk> dims: oh, cool
14:44:54 <dims> dhellmann : so i'd give it another month or so. to reconsitute the team
14:44:54 <fungi> approved
14:45:17 <number80> great
14:45:27 <fungi> dims: do you also have a system-config change to add channel logging?
14:45:31 <dhellmann> dims : yep
14:45:34 <fungi> or is that already in place?
14:45:36 <dims> the etherpad is brimming with information https://etherpad.openstack.org/p/requirements-tasks
14:45:53 <dims> fungi : y, i have one
14:46:10 <dirk> dims: indeed, the etherpad is a great read. it needs a more permanent place though
14:46:15 <dims> fungi : https://review.openstack.org/#/c/315528/
14:46:21 <fungi> k, we'll get it merged the next time there's a lull in meetings. maybe this afternoon americas time
14:46:34 <dims> dirk : yep the idea is for the new team to figure that out
14:46:47 <dims> fungi : thanks!
14:46:54 <dims> dhellmann : ttx : good enough update?
14:46:59 <dims> dirk : did i miss anything?
14:47:10 <dhellmann> dims : sorry, local distraction, thank you, yes, that's all good info
14:47:24 <dirk> dims: in the etherpad you mean? probably, but since I don't know it, I can't point it out :)
14:47:28 <dhellmann> and thanks again for driving that work, it's going to be a big improvement
14:47:29 <dirk> we'll eventually learn about it
14:47:47 <dims> dirk : https://etherpad.openstack.org/p/requirements-tasks
14:47:54 <dhellmann> let's quickly look at the list of priority reviews
14:47:55 <ttx> a lot of the requirements hate is because it was only reviewed in bast-effort mode with no team owning it
14:48:05 <ttx> so the delays were painful
14:48:18 <dims> ttx : yep
14:48:23 <dhellmann> yeah, cutting down the delay and loosening the rules a bit will make it much easier for folks to live with
14:48:40 <dhellmann> #topic priority reviews
14:49:01 <dhellmann> a lot of these happen to be mine this week, but please mention anything else you think is important
14:49:02 <dhellmann> #link support multiple release notes links: https://review.openstack.org/308546
14:49:09 <ttx> merged
14:49:10 <dhellmann> #link add team pages: https://review.openstack.org/313164
14:49:18 <dhellmann> #link fix previous version detection when there are no tags: https://review.openstack.org/314234
14:49:24 <dhellmann> #link submit constraint when releasing something that is published to pypi: https://review.openstack.org/314111
14:49:30 <dhellmann> #link remove instructions for submitting constraints update: https://review.openstack.org/314113
14:49:37 <dhellmann> #link change email topic tag: https://review.openstack.org/312762
14:49:38 <ttx> add team pages is marked cannt merge
14:49:48 <dhellmann> ugh, ok, I'll fix that
14:50:15 <dhellmann> I don't see that on https://review.openstack.org/#/c/313164/ ttx
14:50:20 <ttx> hm
14:50:38 <ttx> "Strategy  Merge if Necessary
14:50:40 <ttx> Cannot Merge "
14:50:51 <ttx> under Topic ?
14:50:55 <dhellmann> weird, I just see merge if necessary.
14:51:09 <dhellmann> are you looking at PS3?
14:51:10 * ttx clicks rebase for fun
14:51:15 <ttx> yes
14:51:31 <ttx> conflict during merge
14:51:35 <ttx> wth
14:51:39 <dhellmann> ok, I'll look at that
14:51:46 <ttx> doesn't prevent W+1
14:52:05 <ttx> "cannot be merged due to a path conflict"
14:52:17 <ttx> "rebase the change"
14:52:23 <dhellmann> let me try locally
14:52:29 <ttx> weird that I would be the only one to se that :)
14:52:41 <ttx> see*
14:52:43 <fungi> no, i see it too
14:52:54 <ttx> I AM NOT CRAZY
14:52:55 <dhellmann> yeah, I see a conflict when I rebase locally
14:52:57 <dhellmann> ok, I'll fix it
14:53:10 <fungi> "cannot merge" is in red to the right of "strategy: merge if necessary"
14:53:56 <dhellmann> ew, ugly conflict, I'll have to work on that after the meeting
14:54:01 <dhellmann> #topic open discussion
14:54:04 <IgorYozhikov> I have topic raised in  http://lists.openstack.org/pipermail/openstack-dev/2016-May/094827.html
14:54:06 <dhellmann> is there anything else to bring up?
14:54:15 <dhellmann> hi, IgorYozhikov
14:54:18 <IgorYozhikov> dhellmann, yes ^^
14:54:20 <dhellmann> did my reply on that thread help?
14:54:47 <dims> IgorYozhikov : we can't really dictate what packagers do
14:54:50 <dhellmann> I just echoed some of what odyssey4me said
14:55:02 <dims> IgorYozhikov : we can just publish what we test
14:55:06 <dhellmann> yes, we're trying to help without forcing you to package anything in particular
14:55:39 <dhellmann> does that make sense?
14:57:44 <odyssey4me> heh, dhellmann it was actually prometheanfire - not me :)
14:57:48 <IgorYozhikov> more || less, just want to get clear 4 newton cycle and how to package dependencies in case of broader requirements usage
14:57:55 <odyssey4me> unless I've totally missed something
14:58:02 <dhellmann> odyssey4me : oops, sorry
14:58:47 <fungi> one of the challenges with trying to test older versions of deps is that many projects conditionally enable features when newer versions of their deps are present, so hard to test those features on older versions
14:59:04 <dhellmann> IgorYozhikov : ok. Our recommendation is that you package what is listed in the constraints file, if you can. If you cannot, then use the global-requirements.txt list to determine a lower-bound, but understand that we do not test with those actively and so there may be issues that are fixed by packaging a newer version of something.
14:59:05 <IgorYozhikov> dhellmann, sorry, just saw your answer.
14:59:25 <IgorYozhikov> dhellmann, thanx.
14:59:25 <dhellmann> fungi : very good point. that's going to make adding a lower-constraints test job interesting.
14:59:38 <dhellmann> IgorYozhikov : good, let us know if we can help clarify further
14:59:47 <IgorYozhikov> sure
15:00:01 <dhellmann> we're about out of time here, so I'm going to call the meeting and free up this channel. We can move to #openstack-release for more discussion.
15:00:04 <dhellmann> #endmeeting