13:01:36 <ttx> #startmeeting releaseteam
13:01:37 <openstack> Meeting started Mon Jun 29 13:01:36 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:40 <openstack> The meeting name has been set to 'releaseteam'
13:01:51 <ttx> Agenda for today at https://wiki.openstack.org/wiki/Release_Cycle_Management#Meeting
13:02:11 <ttx> you can add extra topics as-needed
13:02:22 <ttx> #topic Liberty-1 milestone postmortem
13:02:41 <ttx> We used https://etherpad.openstack.org/p/HxkvsrXqgu to track work there
13:03:07 <ttx> Came up with a checklist that I think we can publish on the wiki for reuse in future milestones
13:03:24 <ttx> any objection to that ?
13:03:49 <dhellmann> the list worked well for me, so let's start with this one and add things if we find them
13:04:22 <ttx> We had a number of issues with the new tools, most of them fixed
13:04:47 <dhellmann> milestone.sh needs some work to be more idempotent
13:04:59 <ttx> I'll move the remaining tasks to our main wiki page
13:05:13 <ttx> agreed on idempotency
13:05:30 <ttx> our mix of shell and python isn't ideal for that though
13:05:43 <ttx> which is why I deferred that task forever now :)
13:05:46 <dhellmann> yeah, I was thinking about that last week when thinking about the automation tool
13:06:12 <dhellmann> I might rewrite release_postversion.sh in python, converting bits of it to a library that makes reuse easier
13:06:14 <ttx> We'll come up with some python library to do the tagging and all
13:06:42 <ttx> I suspect there is some git python library we can use to avoid shelling out from python
13:06:58 <dhellmann> we might even be able to reuse parts of pbr
13:07:14 <ttx> yep, this is more an enhacement once we cover the urgent stuff
13:07:20 <dhellmann> right
13:07:49 <ttx> I'll take the action to break up that etherpad into a checklist and a number of tasks on the main etherpad
13:08:05 <ttx> #action ttx to break up the L1 etherpad into a checklist and a number of tasks on the main etherpad
13:08:32 <ttx> anything else on liberty-1 ? I think we survived the transition to new tracking / new versioning gracefully
13:08:48 <dhellmann> yes, it has gone fairly smoothly so far
13:09:05 <dhellmann> have we had any feedback from the distros, or is it too early for them to be looking at packaging?
13:09:31 <ttx> no feedback yet
13:09:39 <ttx> probably too early
13:09:45 * ttx checks
13:10:13 <ttx> done at Ubuntu
13:10:19 <ttx> https://launchpad.net/ubuntu/+source/nova
13:10:24 <ttx> 2:12.0.0~b1-0ubuntu1
13:10:32 <dhellmann> good
13:10:48 <ttx> means we ahven't completely borked our communication plan around this
13:11:07 <ttx> alright, next topic
13:11:15 <ttx> #topic Deliverables
13:11:32 <ttx> Wanted to discuss this concept and see how we can make progress on it, if we need to
13:11:46 <ttx> the idea is that there already are a number of repositories that are released in sync
13:11:57 <ttx> by in sync I mean with same tag at the same time
13:12:10 <ttx> the archetypal example here is openstack/neutron*
13:12:14 <ttx> well
13:12:17 <ttx> no
13:12:28 <ttx> openstack/neutron + openstack-neutron-*aas
13:12:48 <ttx> since those days a lot of things are called openstack/neutron*
13:13:02 <dhellmann> would you expect the releases for those things to all use the same release notes?
13:13:14 <ttx> Those 4 repos are tagged at the same time with the same version number, and form a single "deliverable"
13:13:28 <ttx> dhellmann: they do. Also share the same Launchpad project
13:13:32 <dhellmann> ok
13:13:39 <ttx> which makes "release pages" quite consistent on that end
13:13:50 <ttx> We have another project that has the same profile
13:14:06 <ttx> openstack/sahara releases together with sahara-extra and sahara-image-elements
13:14:17 <dhellmann> in that case using the same file in the releases repo might make sense
13:14:32 <ttx> right, which is why I think it should be deliverable-oriented
13:14:35 * dhellmann checks to see if that spec is approved
13:14:55 <dhellmann> no, it's not
13:15:00 <dhellmann> #link https://review.openstack.org/#/c/191193/
13:15:13 <dhellmann> I thought we might get that approved last week, and I might start building the tool, but that didn't happen.
13:15:30 <ttx> Now, if we recognize that this concept exists, I think we need to take over releasing for sahara-extra and sahara-image-elements. So far Sergey has been on deck to tag at the same time
13:15:34 <dhellmann> I could update the spec to make it work for deliverables, since it's a relatively minor change to the filename and schema
13:15:54 <ttx> dhellmann: yeah, i wouldn't bother on spec and just iterate on format/tool
13:15:56 <dhellmann> yeah, we should probably do all of them
13:16:04 <dhellmann> ok
13:16:32 <ttx> I don't see any other obvious candiadte, though I think some of the -ui projects would like to do the same
13:17:00 <ttx> My main question at this point is.. if we recognize those are things, where should we keep track of them
13:17:25 <dhellmann> the yet-to-be-created releases repository seems like the obvious candidate
13:17:29 <ttx> I can see some value in introducing the concept in projects.yaml (since that would allow deliverable-level tags), but that may be overkilkl
13:17:34 <dhellmann> one file per deliverable per branch, as you proposed
13:18:06 <dhellmann> yeah, let's try to keep the format there simple if we can
13:18:11 <ttx> Right, we could consider that a release property and just encode it in the release system
13:18:29 <ttx> because that is what it is... describe how to release that "thing"
13:18:35 <dhellmann> right
13:19:11 <ttx> my only objection would be that from a use point of view, they should consume deliverables, not repositories
13:19:16 <ttx> user*
13:19:55 <ttx> i.e. it's easier for them to be presented with deliverables, rather than hunt down some obscure repo to find that sahara comes with sahara-extra
13:20:32 <ttx> and therefore if those are the things users see, and tags are meant to describe things for users... at least some tags would make better sense being applied at deliverable-level
13:20:36 <dhellmann> we could use the release data to render some web pages, too, if that would be useful
13:21:02 <dhellmann> but I see what you mean
13:21:22 <ttx> practical example: the project list on the website. They want to see "sahara" there, not openstack/sahar distinct from sahara/extra
13:21:55 <ttx> which is why I'm still a bit hesitant to keep it completely off the governance repo
13:22:08 <ttx> but then, the release repo definitely is the right place to start
13:22:12 <dhellmann> if we add deliverables as a parallel construct to "projects" and just refer again to the repo names, that won't break any of the tools currently parsing the projects.yaml file and will give us the deliverable relationships
13:22:59 <dhellmann> the other option is to add a layer under "projects" to name each deliverable, but that's going to break some other tools
13:23:37 <ttx> dhellmann: thought about the first option but you end up with either a lot of one-repo deliverables, or tags that can't be applied at that layer
13:24:07 <dhellmann> either way we have a lot of one-repo deliverables, don't we?
13:24:10 <ttx> anyway, we'll see about introducing it at governance layer and the cost/benefit there
13:24:19 <ttx> it's not really our call, but the TC's
13:25:07 <dhellmann> true
13:25:08 <ttx> Let's move on
13:25:20 <ttx> i'll try to mock up how it could look like to minimize tool disruption
13:26:01 <dhellmann> ok
13:26:03 <ttx> #topic Bug branches
13:26:13 <ttx> dhellmann: i s
13:26:18 <ttx> aah
13:26:29 * dhellmann hands ttx a fresh keyboard
13:26:42 <ttx> dhellmann: I suspect you were the one adding the note about those on the etherpad ?
13:26:50 <dhellmann> yes, that's right
13:26:55 <ttx> light yellow
13:27:10 <ttx> could you summarize for the audience ?
13:27:11 <dhellmann> the idea here is to have something that acts like a feature/ branch, where it's tested against master, but isn't called "feature"
13:27:39 <dhellmann> we had a case last week where it would have been convenient to release an oslo library not off of master, but we didn't want to create a stable branch for it yet
13:28:05 <dhellmann> bug branches would let us do that, cutting a branch from say 1.12.0 to release 1.12.1, requiring a backport but not pulling everything from master
13:28:25 <dhellmann> IIRC, the case was oslo.db because master no longer includes the namespace package, so we'll be releasing 2.0.0 this week
13:28:30 <ttx> to me it's more like a release branch (the same way we branch off rc1 before release) that we craete after-the-fact
13:28:58 <ttx> my question is.. why did you need 1.12.1 ?
13:29:00 <dhellmann> yeah, I wanted to be careful with the name to reflect that it is really meant for bug releases only
13:29:16 <dhellmann> there was a minor fix that was in master but it landed after the namespace removal
13:29:31 <dhellmann> I think they ended up working around it, since we didn't get the branch stuff merged
13:29:41 <dhellmann> the zuul change landed, but https://review.openstack.org/#/c/195724/ is needed, too
13:29:50 <ttx> So, my take on it is that it's a slippery slope
13:30:36 <ttx> you don't want to do that for minor things, only in exceptional cases. Otherwise you'll end up with everyone trying to backport a change without some other changes and asking for point releases outside of stable branches
13:30:55 <dhellmann> I think, as we go on, this is something we're going to find ourselves wanting to do infrequently, but when we do want it, it will be more expedient than correctly reverting feature changes
13:31:14 <dhellmann> yes, we would definitely want to make it clear this is for exceptional cases
13:31:25 <dhellmann> dims, do you remember what the oslo.db bug fix was for?
13:31:29 <ttx> I think it's a tool in our toolkit for libraries, where we encourage people to only use tagged things
13:31:37 <dims> dhellmann: lookng up
13:31:47 <ttx> For services (where we support consuming master branch directly) not so much
13:31:54 <dhellmann> yes, that feels appropriate
13:32:21 <dims> "Remove implicit RequestContext decoration"
13:32:27 <dhellmann> we *may* want to use it for security fixes for server projects going to intermediate releases, but I think that's the only case
13:32:30 <dims> Change-Id: I143f30c41e788c7aa9887c0e994f49ee55c94651
13:32:35 <ttx> I just fear that every security fix will trigger one of those now
13:32:40 <dhellmann> ah, right, oslo.db was using oslo.context but didn't declare it's dependency on it
13:33:21 <dims> dhellmann: y and neutron did not like some decoration that was happening in enginefacade i think
13:33:34 <ttx> i.e. you would end up having to do stable releases but also backport for current master release, in addition to master
13:33:36 <dhellmann> ttx: well, we only have to approve them in cases where a non-backwards compatible change is in master
13:33:51 <dhellmann> and that will come up much less often for server releases
13:33:57 <ttx> so only when you bump X ?
13:34:13 <dhellmann> only when bumping X would happen if you release from master, yes
13:34:50 <dhellmann> we could have done all of this using a feature branch, but I thought the name "feature" was misleading enough to introduce a new branch type
13:34:57 <ttx> I'd still keep that option for significant things. Security fixes, regressions in last release, crazy bug
13:35:12 <ttx> that we can't wait to fix
13:35:28 <dhellmann> right
13:35:41 <ttx> basically things where there is time pressure and asking people to bump to X+1 in thaht timeframe is unreasonable
13:35:57 <dhellmann> when we get to the point where we're releasing all the libs weekly, we'll have much less pressure to do one of these anyway
13:36:04 <ttx> it's the same story as feature branches. It's a great tool to have, but a slippery slope if everything is developed this way
13:36:09 <dhellmann> right
13:36:17 <ttx> which is why creating them goes through some oversight
13:36:41 <ttx> I definitely agree bug branches are a thing though, so we might want to document them
13:36:56 <ttx> (the feature branch chapter in project team guide is still due anyway)
13:37:04 <dhellmann> ok, I will add a bug branch chapter
13:37:16 <dhellmann> #action dhellmann document using bug branches in project team guide
13:37:48 <ttx> anything else on that topic ?
13:38:05 <dhellmann> none here
13:38:15 <ttx> ok, next topic then
13:38:20 <ttx> #topic New release model tags
13:38:38 <ttx> I started jolting notes on the maion etherpad and split them out to:
13:38:43 <ttx> #link https://etherpad.openstack.org/p/new-release-tags
13:39:09 <ttx> Basically, with the recent changes I'm not sure the current release model tags help us or anyone
13:39:23 <ttx> I listed the current taxonomy at the top
13:39:47 <ttx> Then the issues we have with it, which make them painful to use for us to determine anything
13:40:02 <ttx> Let me summarize here
13:40:09 <ttx> Currently we have:
13:40:19 <ttx> release:managed (missing some managed stuff, applied at repo level)
13:40:26 <ttx> release:at-6mo-cycle-end (includes all services with a final $series release)
13:40:34 <ttx> release:independent (means will do intermediary releases, or does not follow milestones)
13:40:40 <ttx> release:has-stable-branches (means it has stable/$series)
13:40:56 <ttx> Issues we have with that taxonomy:
13:41:05 <ttx> at-6mo-cycle-end does not include client libraries (basically it is used to also mean type:service) so it's misleading to our users
13:41:16 <ttx> has-stable-branches is not applied to things that do stable/1.0 for example, so it's misleading too
13:41:33 <ttx> has-stable-branches currently really means that there is a final release at end of cycle ... precisely what at-6mo-cycle-end should really mean.
13:41:47 <ttx> independent may actually not be independent (difficult to understand when combined with others)
13:42:25 <ttx> I'd like to come up with something that (1) conveys useful information to consumers in general and (2) that we can still use to derive tooling and policy
13:42:37 <ttx> I think the current model fails at both now
13:42:50 <dhellmann> yes, I agree it's not sufficient
13:42:56 <ttx> release:managed is still pretty ok, it should just be applied at team level
13:43:03 <dhellmann> the new tag definitions look more useful, based on what we just did for this milestone
13:43:07 <ttx> its meaning is clear and we have a use for it
13:43:40 <ttx> theer are basically 3 release models, and communicating which follows what is, I think relevant to all
13:44:10 <ttx> making the 3 release models a combination of other properties of which not all combinations are possible was, I think, a mistake
13:44:32 <ttx> just the result of design by committee on that initial set of tags, and pressure from projects that wanted to collect all possible tags
13:44:55 <dhellmann> we were also trying to be narrowly focused
13:45:30 <ttx> and we didn't have type:service/library
13:45:36 <ttx> so we encoded a bit of it there
13:46:07 <dhellmann> yes
13:46:19 <ttx> To answer your etherpad question...
13:46:25 <dhellmann> I'd like, eventually, for the distinctions based on type to be less important
13:46:48 <ttx> If the project intends to make a release, even if it never pushed a tag, it should use model-independent
13:47:45 <dhellmann> I corrected my verb tense to make that question more clear -- I'm thinking of things like tools directories or specs that are never "released"
13:48:29 <dhellmann> the second case is someone just not getting around to applying a tag in the governance repo
13:48:51 <ttx> dhellmann: I think the second case should be model-independent. But I see your point
13:49:05 <dhellmann> so we default to independent unless otherwise specified?
13:49:11 <ttx> one chooses to actively have no release. So having a tag to describe that might be good
13:49:27 <ttx> dhellmann: I think you are right
13:49:36 <ttx> no tag should mean "we have no idea yet"
13:49:58 <dhellmann> yeah, it's annoying to have to do that but from a browsability perspective I think we need it
13:50:30 <ttx> also we can see with project repo additions that they often come with no tag
13:51:00 <ttx> and that should therefore convey the "unknown" state or a non-affirmative default state (like "well, no idea yet")
13:51:01 <dhellmann> yes, I was thinking of writing a little test thing to require some release indicator, and anything else we know we want at least one of
13:51:34 <ttx> no-release is affirming "we know this won't get released"
13:51:37 <dhellmann> to do that, we would need a release:model-no-releases or soemthing
13:51:42 <dhellmann> right
13:51:45 <ttx> different from "well, we haven't decided yet"
13:51:57 <dhellmann> that makes the list_projects_by_tags tool simpler, too
13:52:17 <ttx> it's also slightly disjoing from tags. The governance repo for example has tags, but isn't released
13:52:55 <ttx> ok, I think we are onto something on the model side, that leaves stable branches
13:53:17 <ttx> I thihnk that tag has no valud if it's not attached to a stable branch policy
13:53:28 <ttx> otherwise you don't know what you get
13:53:46 <ttx> so there is value for "follows-stable-branch-policy"
13:53:57 <dhellmann> don't we have a policy on stable branches already? or is that just tribal knowledge, and not written down?
13:54:02 <ttx> which is slightly clearer than "managed-by-stable-maint-official"
13:54:16 <ttx> we have a policy, but it's enforced by the stable-maint team
13:54:26 <ttx> there are rogue stable branches out there
13:54:46 <ttx> things that the stable branch policy won't support for one reason or another
13:54:52 <ttx> stable branch team I mean
13:54:59 <dhellmann> so maybe we need stable:managed, stable:follows-policy, stable:independent
13:55:11 <ttx> I'd argue that the first two are the same
13:55:27 <ttx> since the only thing the stable-maint-core team does is ensure that policy is followed
13:55:38 <dhellmann> ah, ok then
13:55:47 <ttx> I just don't see the value of stable:indep I guess
13:55:57 <ttx> "some" backports ?
13:56:12 <dhellmann> I think it's useful to indicate that a project does backports, and may maintain more old versions than policy requires
13:56:33 <dhellmann> that's the gnocchi case, right?
13:57:02 <ttx> yes, the gnocchi case is that it follows a different policy
13:57:17 <ttx> undocumented so I can't tell what I get there
13:57:25 <ttx> I suspect, some backports.
13:58:02 <ttx> but can they break me ? no idea? Is config option addition fair game ? dunno. Can I change strings ?
13:58:14 <ttx> will my translation hold ?
13:58:19 <dhellmann> right, so if the idea is to provide more info to users, telling them "there's some sort of backport policy, but it's not standard" at least lets them know to talk to the dev team about it
13:58:31 <ttx> ok, I can see that
13:58:32 <dhellmann> or look for it to be documented elsewhere
13:59:12 <dhellmann> and maybe we end up with some new "policy" evolving out of projects copying what they do, and then they can document that in the governance repo eventually
13:59:36 <ttx> OK, will work on all that as soon as we manage to pass the current round of horizontal changes
13:59:51 <dhellmann> ++
13:59:56 <ttx> Last topic was Server versioning: mapping versions to series
14:00:01 <ttx> but no time left
14:00:13 <ttx> it was about rediscussing how to achieve that
14:00:33 <ttx> we can move that to #openstack-relmgr-office
14:00:40 <ttx> Thanks everyone!
14:00:41 <dhellmann> ok
14:00:43 <ttx> #endmeeting