14:00:10 <dhellmann> #startmeeting releaseteam
14:00:11 <openstack> Meeting started Fri Mar 25 14:00:10 2016 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:14 <openstack> The meeting name has been set to 'releaseteam'
14:00:17 <dhellmann> courtesy ping: ttx, dims, lifeless
14:02:43 <ttx> o/
14:03:04 <dims> o/ (50%)
14:03:14 <dhellmann> our agenda for today is under the R-2 week in https://etherpad.openstack.org/p/mitaka-release-tracking
14:03:32 <dhellmann> #topic Mitaka release issues
14:03:40 <dhellmann> #info Aggressively releasing requirements updates in stable/mitaka: min or patch update
14:03:57 <dhellmann> #undo
14:03:58 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x2efee10>
14:03:59 <dhellmann> #info Aggressively releasing requirements updates in stable/mitaka: min or patch update?
14:04:00 <ttx> I tried to list all the issues, I may have missed some
14:04:18 <dhellmann> I think we agreed for this one that we should go ahead and apply semver rules, is that how you remember it?
14:04:34 <ttx> so we'd do min update
14:04:41 <dhellmann> that is, we should allow min version updates if the requirements changes dictate them
14:05:02 <ttx> ok
14:05:09 <dhellmann> some of the changes may not, though
14:05:24 <dhellmann> #agreed apply SemVer rules and raise minimum values where appropriate
14:05:33 <dhellmann> #info mitaka ahead of master in pbr (and getting worse if we release on stable/mitaka: should we aggressively release on newton to close the gap ?
14:05:34 <ttx> works for me, I think if we release we create the master < stable situation anyway
14:05:40 <dhellmann> right
14:05:50 <ttx> so we can do 3 things here
14:06:00 <ttx> release a Y+2 after the Y+1
14:06:12 <ttx> (or around the same time)
14:06:22 <ttx> pass a dummy sem-ver: thing so that PBR is happy
14:06:28 <ttx> ignore it as non-relevant
14:06:47 <ttx> the thread seems to oscillate between the three
14:07:01 <dhellmann> we would have to do 2 semver update instructions, right?
14:07:21 <dhellmann> to have Y+2
14:07:28 <ttx> if we do min patch... probably
14:07:38 <ttx> sigh
14:07:39 <dhellmann> yeah, that feels a bit silly
14:07:57 <ttx> even sillier than Y+2
14:07:59 <dhellmann> my inclination is to ignore it until there's a reason to release anyway, but look for those as soon as possible
14:08:08 <dhellmann> and then do the Y+2 release
14:08:29 <ttx> yeah, maybe "encouraging early releases" is a reasonable compromise
14:08:34 <ttx> so 3+1
14:08:41 <dhellmann> yeah
14:09:12 <dhellmann> #agreed to resolve the master < stable version issue, encourage early newton releases of Y+2
14:09:31 <ttx> it's not as if we didn't have the issue already
14:09:43 <ttx> just try to keep it short, I guess
14:10:00 <dhellmann> exactly
14:10:07 <dhellmann> #info Merging of tags from stable into master
14:10:16 <ttx> So.. what would that solve
14:10:22 <dhellmann> this came up in the ML thread about the versioning
14:10:29 <dhellmann> I don't think it's a solution, I think it may break reno :-/
14:10:47 <ttx> if you merge the tags in master you would still generate racing versions
14:10:52 <ttx> iiuc
14:11:04 <ttx> until you tag master
14:11:13 <ttx> with something that will forever be > stable
14:11:17 <dhellmann> I'll have to take a look at what happens in a reno after a stable tag is merged into master, but I suspect it's going to confuse reno as it scans the tag history backwards
14:11:46 <ttx> yeah, needs more investigation, and not practical for this round anyway
14:11:47 <dhellmann> at least for the "unreleased" pages, so we may need to use the earliest-version setting to prevent it from pulling in a bunch of old data incorrectly
14:11:50 <dhellmann> yeah
14:11:55 <dhellmann> just noting it here as an issue
14:12:04 <ttx> maybe add it to the newton plan so that we investigate it when we have our lives back
14:12:13 <dhellmann> good thought
14:12:24 * ttx is in "defer all the things" mode
14:13:05 <ttx> btw in theory my Monday is a holiday, so I was planning to do a light day
14:13:37 <dhellmann> today is supposed to be a holiday for me (new company, new holiday list), but I'll be around for the morning at least
14:13:54 <dhellmann> #info python-senlinclient situation (wants to do a mitaka patch release but has released 0.4.1 over 0.4.0 on master): fast-forward stable/mitaka to 0.4.1 ?
14:14:04 <ttx> so yeah, this is a bit of a mess
14:14:08 <dhellmann> yeah, wow
14:14:27 <ttx> one more vote for removing tag rights to everyone
14:14:42 <dhellmann> we should add a step to approving new projects as official that the release team helps them straighten out their tagging, and takes that over
14:14:42 <ttx> I'd say we can do two things
14:15:06 <ttx> one - do nothing, d not rele&ase and have stable/mitaka be a dead branch
14:15:07 <dhellmann> the tag is on master? that's worse than I thought
14:15:27 <ttx> pray that there is no CVE
14:15:31 <ttx> etc
14:15:45 <ttx> two - fast-forward stabel/mitaka to 0.4.1
14:15:53 <dhellmann> I think I'd rather do that
14:16:03 <ttx> i.e. remove the branch and recreate it
14:16:10 <ttx> It's something we have done in the past
14:16:13 <dhellmann> or merge those commits into stable?
14:16:26 <ttx> no waot
14:16:28 <ttx> wait
14:17:06 <dhellmann> fixing the branch, one way or the other, is more work now but it's one less special case to keep up with for later
14:17:07 <ttx> For horizon we did that in the past. We had a milestone/$series cut
14:17:19 <ttx> but then they had 30 fixes on master
14:17:23 <ttx> all to be backported
14:17:37 <ttx> rather than go through the backport dance, we just recreated proposed/$series
14:17:52 <ttx> pointing to the newer commit on master
14:18:09 <dhellmann> ok, if there's precedence for that it's fine with me. I thought we could propose a review for a merge commit on the stable branch, but that may not get the tag right
14:18:27 <ttx> The only difference here is that we could delete proposed/$series alright. For stable/* we need to go through infra
14:18:51 <dhellmann> I can talk with fungi about removing that branch and then I can recreate it at 0.4.1
14:19:03 <ttx> dhellmann: only drawback is that it tends to confuse people that have been following that branch
14:19:03 <dhellmann> I'll also suggest to Qiming that they let us tag from now on
14:19:16 <ttx> but I think that's a reasonable trade-off
14:19:24 <dhellmann> yeah, I think it's ok in this case
14:19:42 <ttx> the alternative solutions are just way worse
14:20:01 <dhellmann> ttx: how about the 0.5.0 question with the incompatible changes?
14:20:08 <dhellmann> I think we want them to leave those on master
14:20:24 <ttx> so yeah, make 0.4.1 their stable/mitaka initial release, backport on top of that
14:20:32 <ttx> make 0.4.2 on stable/mutaka
14:20:46 <ttx> then they can do a 0.5.0 on master if they want to
14:20:51 <dhellmann> right
14:21:00 <dhellmann> and it will be part of newton
14:21:14 <ttx> we could post the accompanying ACL change to get tagging to library-release
14:21:38 <dhellmann> yeah, I'll do that
14:22:02 * ttx checks if anything landed on stable/mitaka
14:22:24 <ttx> hrm
14:22:27 <ttx> so one complication
14:22:35 <ttx> they have two commits landed there
14:22:42 <ttx> http://git.openstack.org/cgit/openstack/python-senlinclient/log/?h=stable/mitaka
14:22:51 <dhellmann> one is the .gitreview and the other is a requirements update
14:22:53 <ttx> in the horizon precedent it was a clean ref
14:23:03 <dhellmann> both will be regenerated when the new branch is created
14:23:21 <ttx> i.e. pointing to a master commit, deleting the branch only removed the ref
14:23:25 <dhellmann> do you think it would be safer to just propose the merge from master into the branch?
14:23:41 <ttx> that would not solve the issue
14:23:50 <ttx> you want the SHA of the 0.4.1 tag
14:24:02 <ttx> so that you don't redo it or anything
14:24:14 <ttx> I think it's fine to "lose" those two commits
14:24:20 <ttx> I'll see with fungi
14:24:38 <dhellmann> ok, I'm not sure why the merge doesn't work but that's fine
14:24:47 <dhellmann> I can work through that on my own time :-)
14:24:58 <dhellmann> shall we move on to missing releases?
14:25:02 <ttx> yep
14:25:06 <dhellmann> #topic Missing fresh intermediary releases & stable/mitaka
14:25:46 <ttx> I listed all the things we are still missing
14:25:47 <dhellmann> we have bifrost, magnum, monasca, python-searchlightclient, senlin-dashboard, solum-infra-guestagent, and os-win without recent releases
14:25:56 <ttx> monasca just got proposed
14:26:02 <dhellmann> ok, good
14:26:17 <dhellmann> I'll review and process that today
14:27:09 <ttx> while you talk to Qiming you can mention senlin-dashboard
14:27:44 <dims> o/ (sorry had a conflict)
14:27:50 <dhellmann> what's our deadline for these projects? next week is final RCs but the final release is listed as the week after. I'll bet some are waiting for that.
14:28:14 <ttx> yep, they can do next week still
14:28:31 <dhellmann> I can include next week as the deadline in my reminder email
14:28:33 <ttx> but they should ta least know they are exposing themselves to some random failures
14:29:14 <dhellmann> right
14:29:15 <ttx> planning on releasing Friday next week is just taking unnecessary risks
14:29:19 <dhellmann> yeah
14:29:24 <ttx> better release now and update it if needed
14:29:27 <dhellmann> ok, I'll include that in the reminders
14:29:32 <ttx> at least we have a decent fallback then
14:29:33 <dims> +1 ttx
14:29:56 <ttx> I just don't want people complaining CI was broken Friday and asking for an exception to get in on release week
14:30:12 <ttx> I want them to know the risk
14:30:50 <dhellmann> yeah, I'm going to tell folks we won't be doing any more intermediary releases after thursday of next week unless it's critical, and that the release team will have reduced availability between that date and the summit
14:30:51 <ttx> also those who promised it for this week should deliver
14:31:17 <ttx> no point in saying "Wednesday and then miss it and not keeping us informed
14:31:31 <ttx> makes us nervous and all
14:31:36 <dhellmann> right
14:31:56 <dhellmann> #topic Missing but was not in liberty nor in mitaka yet so meh
14:32:02 <dhellmann> for these, we had cloudkitty and tacker
14:32:18 <ttx> right, thoise are slightly less critical for us... if they miss it's on them only
14:32:29 <dhellmann> tacker is new and has an eta of Mar 31
14:32:42 <dhellmann> cloudkitty is on my list to remove as an official project
14:32:56 <ttx> we can't afford to skip a release on things that were in liberty as easily
14:33:51 <ttx> They are still technically on time
14:34:07 <dhellmann> ok, I'll try to track down someone who can tell me what's going on
14:34:08 <ttx> we should document clearer that "intermediary" means "making intermediary releases"
14:34:22 <ttx> I got some updtes from cloudkitty
14:34:26 <dhellmann> oh, good
14:34:32 <ttx> told me today or over the weekend
14:34:52 <dhellmann> ok
14:35:22 <ttx> Let's put them in the remidner today, and then chase them down Tuesday if they still haven't shipped
14:36:08 <dhellmann> why do you consider it more important to chase them down because they were included in liberty?
14:36:29 <dhellmann> I'm not disagreeing, just trying to understand that reasoning
14:36:36 <ttx> dhellmann: for continuity I guess
14:36:56 <ttx> something that released in liberty and would not be in mitaka would certainly be grounds for project removal
14:37:04 <ttx> (in my book)
14:37:09 <dhellmann> ok. I guess I consider that we are going to potentially drop projects at any point in their life cycle, and -- yeah
14:37:31 <ttx> dropping and disappearing is ~fine
14:37:40 <ttx> flapping, not so much
14:37:46 <ttx> or missing the date
14:38:04 <dhellmann> I would want them to demonstrate for at least a cycle that they were still active before bringing them back in, but yeah, I see that point
14:38:24 <ttx> something that was never there... well it's still not there
14:38:35 <ttx> from a releases.o.o perspective it's clean
14:38:52 <dhellmann> that's a good segue to our next topic
14:38:56 <dhellmann> #topic what to do with old release data for unofficial projects
14:39:17 <dhellmann> we have openstack-ansible and tacker both with historical release data in the releases repo
14:39:37 <ttx> yeah, so on one hand it's sad to "lose" information, but for the sake of clearly saying what is official and what's not, I think we need to get rid of pre-offciial releases in releases.o.o
14:40:17 <dhellmann> I've proposed changes to do that
14:40:22 <ttx> we should not add deliverables to an already-released release basically
14:40:23 <dhellmann> #link https://review.openstack.org/297298
14:40:29 <dhellmann> #link https://review.openstack.org/297666
14:40:38 <dhellmann> yeah, that's more clear to me now
14:40:59 <dhellmann> for tacker, it was easier for me to help them get the releases done this way, but I should just have gotten the sha values from them directly instead
14:40:59 <ttx> It's not about being mean, it's about not rewriting history
14:41:12 <dhellmann> sure
14:41:41 <dhellmann> there's also the situation of expecting the teams to figure out how to do this themselves, though
14:41:41 <odyssey4me> o/ FWIW, I'm happy with that resolution. It makes sense for releases to be used from a point-in-time forward.
14:42:04 <dhellmann> what do you think about having an _unofficial directory under the deliverables tree that isn't published?
14:42:25 <ttx> dhellmann: we kinda have the same issue for non-official things asking for a release
14:42:43 <odyssey4me> That sounds like opening up a lot of work for a small release team?
14:43:02 <dhellmann> right. I'm trying to think ahead with projects that want our help with releases, and to make that easier on us. Putting all of the requests through the same process simplifies things.
14:43:06 <ttx> yeah, not sure we should handle pre-historic releases
14:43:21 <ttx> but then the cost is limited
14:43:25 <dhellmann> odyssey4me : in the long run it may be less work, since it means we can ensure that teams do their releases correctly earlier
14:43:33 <dhellmann> so we end up with less to clean up after the fact
14:43:35 <ttx> dhellmann: arguably we should not announce those on openstack-announce either
14:43:50 <dhellmann> sure, we could make the script smart enough for that, too
14:44:07 <dhellmann> fwiw, these would all be part of changes for next cycle, not right now
14:44:17 <dhellmann> so it's just something to think about
14:44:20 <ttx> dhellmann: right, maybe defer-all-the-things this discussion
14:44:59 <ttx> dhellmann: it's true that we'll always have requetss for pre-official releases. And if we want to take tag rights away... simpler that we process them
14:45:06 <odyssey4me> dhellmann fair enough, I think if you can get to the point of automating the tag portion then it's less hand work and just a review burden, which isn't too bad
14:45:12 <ttx> rather than get fancy with ACLs
14:46:02 <ttx> dhellmann: could be some "non-official" header in the yaml
14:46:12 <dhellmann> odyssey4me : right, I'm assuming that, but even now it usually only takes a couple of minutes to wait for the merge and run the tag
14:46:14 <ttx> that would block announces
14:46:18 <dhellmann> ttx: oh, I like that too
14:46:26 <ttx> and block publication on the site
14:46:35 <ttx> but otherwise would tag and all
14:46:40 <dhellmann> right
14:46:51 <ttx> as long as it's clear when you read the file
14:46:58 <dhellmann> I making notes in https://etherpad.openstack.org/p/newton-relmgt-plan
14:47:10 <dhellmann> a flag in the file would be easier to manage than a separate directory, so I like that better
14:47:18 <ttx> dammit, now I failed to defer-all-the-things it
14:47:27 <dhellmann> meh, it's notes for the summit :-)
14:47:39 <dhellmann> I think that's it for the formal agenda
14:47:43 <ttx> yep all done
14:47:43 <dhellmann> #topic open discussion
14:47:55 <dhellmann> is there anything else to raise?
14:48:06 <fungi> let me know when you need help with the branch deletion you were talking about
14:48:20 <ttx> maybe we can discuss it now
14:48:26 <dhellmann> fungi : right after I close the meeting out would be good, if you have time now
14:48:31 <dhellmann> or yeah, even now now :-)
14:49:08 <dhellmann> fungi : we need the stable/mitaka branch for openstack/python-senlinclient removed. I'll recreate it using our tools that generate the .gitreview updates, etc.
14:49:11 <fungi> sure, just need specific details. i was trying to follow along but surprisingly lots going on this morning for being a holiday most places
14:49:40 <fungi> when was stable/mitaka created for openstack/python-senlinclient?
14:49:53 <fungi> i take it the divergence is minor
14:49:57 <ttx> fungi: it was created on the 0.4.0 tag, but then they tagged 0.4.1 on master
14:50:07 <fungi> ahh
14:50:10 <ttx> so we'd rather recreate stable/mitaka over 0.4.1
14:50:17 <dhellmann> yes, the only patches on that branch are the .gitreview update and an auto-generated requirements update
14:50:20 <ttx> rather than having a stable vbranch we can't release from
14:50:34 <fungi> it won't be fast-forwardable, but i guess that's expected collateral damage
14:50:50 <dhellmann> yeah, I think we're all willing to live with that for this case
14:50:51 <ttx> yeah, sounds like better than doing nothing, or removing the tag
14:51:02 <ttx> which are the other two "solutions"
14:51:36 <ttx> not sure what happens to those two commits that have no reference to hold them in the git tree
14:52:03 <ttx> but I bet you know
14:52:26 <dhellmann> they're still valid commits in the graph, right?
14:52:34 <ttx> dhellmann: mayyybe?
14:52:48 * ttx admits ignorance
14:54:55 <dhellmann> ttx: should we go ahead and prepare the update for the service project acls that we need for R-0 and mark it WIP?
14:55:26 <dhellmann> fungi : we're going to close out the meeting here soon, so maybe we should continue the discussion in #openstack-release
14:55:49 <fungi> dhellmann: sure, multiple things happening in multiple channels. am about to pull it up
14:56:04 <dhellmann> ttx: I'm assuming we want to wait for the mitaka library updates until early next week, to avoid releasing right before a holiday weekend
14:56:25 <dhellmann> fungi : right, I expect you're busy, I'm just watching the clock for the meeting slot :-)
14:56:33 <ttx> dhellmann: +1
14:56:40 <dhellmann> ok
14:57:32 <dhellmann> ok, let's go ahead and wrap this up and move back to #openstack-release
14:57:34 <dhellmann> #endmeeting