13:01:13 <ttx> #startmeeting releaseteam
13:01:14 <openstack> Meeting started Fri Jun  5 13:01:13 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:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:17 <openstack> The meeting name has been set to 'releaseteam'
13:01:31 <ttx> I'll follow on https://etherpad.openstack.org/p/liberty-release-mgmt
13:01:45 <ttx> then discuss what we need to do next week if anything
13:01:48 <dhellmann> is there a ceremony for the the first meeting of a new team? :-)
13:01:57 <ttx> it involves dancing
13:02:05 * dhellmann doesn't dance this early
13:02:08 <ttx> #topic Switching release tracking from predicting to reporting
13:02:19 <ttx> So the ugent items have been taken care of
13:02:44 <ttx> In order to be able to generate LP release pages for milestone-following projects at liberty-1 we could use some helper scripts
13:02:58 <dhellmann> yeah, the rest of those changes look like things we can do soon, but aren't needed immediately
13:03:09 <ttx> basically to target completed BPs to the miletsone and remove the milestone target from incomplete ones
13:03:16 <ttx> the same way we do bugs
13:03:19 <ttx> I'll work on that
13:03:31 <dhellmann> k
13:03:55 <ttx> as far as libraries, go we can discuss that later in the meeting
13:04:01 <ttx> s/,//
13:04:07 <dhellmann> ok
13:04:17 <ttx> it's part of a wider discussion on using LP release pages for libraries
13:04:40 <ttx> dhellmann: anything on that topic ?
13:04:56 <dhellmann> no, I think that's all clear for now
13:05:00 <ttx> #topic New PTL/RelMgt coordination
13:05:11 <ttx> So that was put in place
13:05:24 <ttx> I think we'll elaborate the checklist using liberty-1 as a test field
13:05:56 <dhellmann> that sounds good -- I've really only done this for Oslo, and I think we were a special case in a lot of ways, so I'm not sure what you talked about with the other projects
13:06:08 <ttx> We might need a way to commuinicate that one of us will skip office hours
13:06:16 <ttx> (example: me on Tuesday)
13:06:34 <dhellmann> hrm, yes, maybe a wiki page?
13:06:37 <ttx> maybe I should send an email to list
13:06:49 <ttx> that will serve as a reminder that those things exist
13:06:59 <dhellmann> makes sense
13:06:59 <ttx> right + mention it on the wiki page
13:07:22 <ttx> https://wiki.openstack.org/wiki/Release_Cycle_Management
13:07:27 <ttx> is where we announced them
13:07:41 <ttx> #action ttx to announce office hours skip on ML and wiki/Release_Cycle_Management
13:07:54 <ttx> anything else on that topic ?
13:08:33 <dhellmann> just to clarify, the intent is that each project is required to check in during office hours during the milestone week? or the week leading up to it?
13:08:54 <ttx> during the milestone week. Basically the Tuesday in the milestone week
13:09:10 <dhellmann> ok, got it
13:09:33 <ttx> mostly about making sure our scripts caught the right features
13:09:53 <ttx> and getting some understanding on when to push a tag
13:10:05 <ttx> #topic Server Version Numbering (to enable intermediary releases)
13:10:09 <dhellmann> so you'll want to run the script before then?
13:10:19 <ttx> at least a dry run
13:10:28 <dhellmann> k
13:10:39 <ttx> which is why the tool is interesting :)
13:10:49 <dhellmann> maybe the script should just create and populate the milestone, then, and not close it -- that's easy to do in the web ui, after we review it with the ptl
13:11:04 <dhellmann> that way we can keep running the script periodically without any impact
13:11:19 <ttx> dhellmann: ++
13:11:28 <ttx> I think we'll invent it as we go
13:11:28 <dhellmann> well, negative impact
13:11:40 <ttx> So... on server versioning. I had a few questions on how that new server versioning will happen in practice soon
13:11:53 <ttx> "Should everyone go to 12 ? Or things that only had 3 releases should go to 4 ?"
13:12:10 <dhellmann> I left a comment on that just a few minutes ago
13:12:16 <dhellmann> 3.2.1
13:12:26 <ttx> basically I can see how a common version could start getting very confusing when things /start/ to diverge
13:13:01 <ttx> hmm
13:13:13 <ttx> I guess the issue is 'at least some projects'
13:13:13 <dhellmann> if projects are going to want to bump their major version regularly anyway, we could keep that as a "release cycle counter"
13:13:29 <ttx> I totally see how having multiple liberty projects named 12 is a plus
13:13:34 <dhellmann> I think it was the nova team who mentioned schema upgrade compatibility as a factor
13:14:02 <ttx> but if for miyasaki we start seeing 12, 13 and 14, it will be more confusing than having everyone on numebrs that just don't look the same and never did
13:14:32 <ttx> people will assume things from numbers that look consistent
13:14:36 <dhellmann> would we declare major version changes for intermediate releases?
13:14:52 <dhellmann> I guess we could, but I didn't really expect it
13:14:55 <ttx> probably not
13:15:12 <dhellmann> but yeah, I see your point, so maybe we pick a number for each project based on how many releases they have already had
13:15:27 <dhellmann> and just diverge immediately
13:15:30 <ttx> my point is... ironic will diverge, and so will have 12.x or 14.x versions when "some" others will have 13.x
13:15:41 <dhellmann> yeah
13:16:03 <ttx> at least if everyone has a different n,umber nobody will infer anything from common versions
13:16:23 <dhellmann> yeah, I see the logic to that
13:16:27 <ttx> (which is good, because there won't be anything to infer anymore)
13:16:34 <ttx> anyway, just food for thoughts
13:16:49 <ttx> now... "For projects still following the milestone model"
13:16:56 <dhellmann> some projects will have the same numbers, but it will be a show of age
13:17:20 <ttx> would we use 12.0.0 as a preversion ? i.e. just generate 12.0.0b1 instead of 2015.2.0b1 ?
13:17:36 <ttx> (at liberty-1)
13:17:39 <dhellmann> yes, I think we should start using the new versioning immediately
13:17:45 <dhellmann> with the next tag, that is
13:18:02 <ttx> so that means pushing 12.0.0 (or whatever) in all setup.cfg that have 2015.2
13:18:10 <ttx> for some definition of 'all'
13:18:16 <ttx> (to be discussed below)
13:18:39 <ttx> I guess we still have time before l1 to do that
13:18:54 <ttx> but that means closig the discussion on the initial number to pick soon enough
13:19:08 <dhellmann> for semver, using pre-releases might be more complex than just building versions based on what's in git
13:19:32 <dhellmann> so at the milestone we could remove the version and then tag 12.0.0b1 or whatever and go with tags after that
13:20:39 <ttx> right. Basically we would only use preversion for stuff that follows the time-based milestone model
13:20:51 <ttx> for intermediary releases we would use post version
13:21:10 <ttx> fwiw that's how it's done currently for swift (intermediary, post)
13:21:28 <dhellmann> well, the time-based releases are still going to be using semver, right? we're just tagging releases less often for them?
13:22:07 <ttx> yes. preversion doesn't mean semver-incompatible
13:22:22 <ttx> it's just a way to support intermediary tags that are not "releases"
13:22:35 <ttx> so that we can tag milestones and RCs
13:22:50 <ttx> Alternative is to stop tagging  milestones and RCs
13:23:14 <ttx> but I like that those exercise the release machinery in advance of final release
13:23:27 <ttx> and also lets us publish RC tarballs for testing
13:23:46 <ttx> for something released every 6 months I think that still has value
13:24:30 <dhellmann> ok, I'm not sure I see all of that, but I don't want to bog us down in the meeting
13:24:30 <ttx> dhellmann: anything else on that topic ?
13:25:26 <ttx> dhellmann: I think we just need to agree that the goal for things still using the time based milestone development cycle, is to tag them X.Y.0b1 at liberty-1
13:25:41 <ttx> we can evolve our long-term thinking
13:25:49 <dhellmann> ok, that much I do agree with :-)
13:25:58 <ttx> ok, next topic
13:26:04 <ttx> #topic Recentralize library release management
13:26:13 <ttx> I read your draft and added a few words
13:26:36 <dhellmann> I saw
13:26:57 <ttx> I don't thin kthat needs much work beyond agreement
13:26:59 <dhellmann> I didn't actually intend for the teams to continue to do their own tagging, but I guess we could do that.
13:27:21 <ttx> there is the larger discussion at hthe next topic of what we should cover, but we can talk about that next
13:27:46 <ttx> err, did I say they should still tag ?
13:27:53 <dhellmann> line 5
13:27:59 <ttx> if I did that was not my intent
13:28:08 <dhellmann> ah, you mean the release team
13:28:11 <dhellmann> ok, I'll add "release"
13:28:14 <dhellmann> heh
13:28:15 <ttx> done
13:28:29 <dhellmann> k, that matches what I was thinking now :-)
13:28:35 <ttx> no no we should handle the tag. definitely
13:28:45 <ttx> otherwise we don't change anything
13:28:48 <dhellmann> right
13:29:29 <ttx> so one question I had was... what should we try to do Launchpad-wise, if anything
13:29:47 <ttx> currently, if I'm not mistaken, we run the bug-closing script ?
13:30:02 <dhellmann> yes, and release_library.sh creates the milestone if it doesn't exist
13:30:20 <dhellmann> it actually creates the series, too, as a convenience
13:30:25 <ttx> what about blueprints/features ?
13:30:31 <dhellmann> it doesn't handle those, yet
13:30:39 <ttx> so we are.. tolerating them ?
13:30:53 <ttx> but not actively doing anything about them
13:30:57 <dhellmann> it ignores them completely, right
13:31:23 <dhellmann> I think it should target any that are marked as implemented and not already targeted
13:31:27 <ttx> ok, not sure what we should be aiming at there
13:31:29 <dhellmann> I assume that's similar to what the milestone script does
13:31:45 <dhellmann> yeah, if the point is to report on what is done, we should include features, too
13:32:01 <ttx> I guess for library so far the point was:
13:32:22 <ttx> - to generate a history of versions that let you get a good series-oriented graph
13:32:41 <ttx> - to close bugs and associate them with a version number where the fix is in
13:32:53 <ttx> but the goal wasn't to generate useful milestone pages
13:33:01 <ttx> (or release page)
13:33:17 <dhellmann> true, we have the changelog in the docs for the libraries in most cases
13:33:34 <ttx> this is why we are sloppy on blueprints there -- users don't need to know as much in which version the fix appeared
13:33:56 <dhellmann> true, end users don't
13:34:11 <ttx> so yeah, I'm not sure what our objective should be there
13:34:18 <dhellmann> I did try to keep up with that by hand for oslo last cycle
13:34:49 <ttx> currently we have "servers" for which we use the release pages from LP as the changelog
13:35:00 <dhellmann> it seems easy enough to pick up the completed blueprints and add them to the milestones, no? is there a reason to not do that, to report to the other developers?
13:35:11 <ttx> and we have libraries where we just clean up LP so that it doesn't look too weird
13:35:35 * dims_ peeks
13:35:54 <ttx> I think we didn't do that because of the tracking cost, but then that cost is probably limited now that we are just doing tracking rather than prediting
13:35:59 * dhellmann suspects dims has added a watch notifier for "oslo"
13:36:06 <dims_> dhellmann: yep
13:36:30 <dhellmann> right, when I was trying to keep the predictions straight it was a PITA, but now that we're just fixing things up as we release it should be pretty straightforward
13:36:35 <ttx> dhellmann: how about we try to build more complete release pages by reusing whatever script I'll come up with to support servers
13:36:43 <ttx> and see how that goes
13:36:46 <dhellmann> ttx: that's exactly what I was thinking, yes
13:37:02 <ttx> depending on how fast we move on phabricator we'll have to reconsider anyway
13:37:12 <ttx> OK, that's a good segway to the enxt topic
13:37:21 <ttx> #topic Refining release "models"
13:37:26 <ttx> It's not really a good title
13:37:45 <ttx> My point here is trying to make sense of the whole thing now. Trying to put things back into buckets
13:37:52 <ttx> to satify my organization compulsion
13:38:03 <ttx> so, trying to define buckets
13:38:08 <ttx> we have
13:38:20 <ttx> - Purely independent things (think zuul)
13:38:27 <ttx> - "Servers" with a $SERIES release at the end of the cycle
13:38:44 <ttx> (some of them with intermediary releases, some following the milestone/RC model)
13:39:00 <ttx> - Libraries: independent, but with a stable branch cut every 6 months
13:39:25 <ttx> which I think is a more objective way to look at it than "doing a final release every 6 months")
13:39:45 <ttx> but your opinion may vary
13:40:06 <dhellmann> that seems like a good way to describe it
13:40:36 <ttx> Now, if we look at it from the angle of "what are we doing tags/announcements for"
13:41:01 <ttx> Currently we are "managing" all "Servers" with a $SERIES release at the end of the cycle for which we are on the LP drivers team
13:41:05 <ttx> that is a subset of them
13:41:30 <ttx> for example MagnetoDB we can't "manage" right now because we aren't in their drivers team
13:41:38 <ttx> should we fix that ?
13:41:47 <ttx> I think that would remove one special case if we did
13:42:29 <dhellmann> I guess the question is, does being an official project come with optional release management or with required release management?
13:42:49 <ttx> I woud put it slightly differently
13:43:07 <dhellmann> we've said for other cross-project teams that the cp team can decide which projects to work on directly vs. which to work on with a liaison
13:43:16 <ttx> If a project doesn't want us to do its release management, we could consider it's in the "independent" bucket
13:43:42 <ttx> I think the moment they want a stable branch though... they need us
13:43:59 <dhellmann> how independent? do we still include them in status.openstack.org/release?
13:44:01 <ttx> the question is also "should we offer to manage any project"
13:44:26 <ttx> currently we aren't including them on the status page
13:44:42 <ttx> see ? I'm trying to define the territory here
13:44:53 <ttx> from emergent properties of the model
13:45:04 <dhellmann> I'm a bit more comfortable letting milestone-release projects handle a lot more of the work themselves than I am for projects doing intermediate semver releases, because it's easy to get the semver wrong or release something at a bad time
13:45:44 <dhellmann> at least until we have more people with practice doing the intermediate releases
13:46:34 <ttx> should we just consider them case-by-case ?
13:46:38 <dhellmann> so are you proposing that projects that want stable branches and reporting should let us manage that? and does that mean us doing it, or us guiding their liaison?
13:47:00 <ttx> I'm trying to determine where we stop
13:47:11 <ttx> and how to record that somewhere
13:47:46 <dhellmann> we could use a tag in the governance repo to record it
13:47:48 <ttx> Do we need to be involved if they do stable branches ?
13:47:58 <dhellmann> not necessarily
13:48:15 <dhellmann> really, the scheduling of the releases is the trigger for me
13:48:41 <dhellmann> if they're on a 6 month schedule, I think it's safe to guide the liaison via documentation and help on irc
13:48:52 <dhellmann> if they're not, I think we should do it ourselves until we get it automated
13:49:19 <dhellmann> maybe your experience with the liaisons last cycle gives you a different opinion, though?
13:49:56 <ttx> I'd say that for the same reason PTLs get semver wrong, they get PEP440-compliant versioning wrong too
13:50:28 <dhellmann> hmm, ok
13:50:30 <ttx> especially the subtleties of 2015.2.0b1 instead of 2015.2.b1 or 2015.2b1 or 2015.2.0.b1
13:50:41 <dhellmann> yeah, that's a good point
13:50:46 <ttx> so I think we need to own the tag
13:51:02 <dhellmann> ok, so does my email need to change to be about all projects?
13:51:16 <ttx> one fight at a time
13:51:29 <dhellmann> ++
13:51:47 <ttx> today's fight is more to convince PTLs where we already to tagging for their main stuff to give us libraries back
13:51:56 <ttx> s/to/do
13:52:23 <ttx> tomorrow's fight (which I'm not sure we should do) is to go beyond the old set of integrated release and incubated
13:52:29 <dhellmann> ok, let's keep those conversations separate then
13:52:36 <ttx> which needs to be bigtented
13:52:59 <dhellmann> if we get this automated properly, it shouldn't actually be that much more work to approve tags for everything
13:53:28 <ttx> So I'd say it needs to be opt-in for projects, and we need to be comfortable with the addition
13:53:47 <ttx> we can start the "managed" set using the old integrated+incubated
13:53:56 <dhellmann> and if they want to continue to do it, we can verify their version numbers if they ask?
13:54:02 <ttx> sure
13:54:12 <dhellmann> I think that's a good way to handle it for now
13:54:16 <ttx> as far as trafcking goes we do tracking only for managed stuff
13:54:31 <ttx> which leads to the next question
13:54:39 <dhellmann> do we need to define a tag for the governance repo to indicate release-managed or something?
13:55:26 <ttx> right. that is what I kind of wanted to avoid by aligning us with an already-existing bucket
13:55:33 <ttx> like "it has stable branches"
13:55:53 <ttx> also don't want it to become a new badge
13:56:10 <dhellmann> ah, I see
13:56:15 <ttx> basically we need to simplify the process faster than we add new projects
13:56:19 <dhellmann> right
13:56:26 <ttx> interesting challenge
13:56:29 <dhellmann> so let's not add a tag, and just keep track of a list ourselves somewhere for now
13:56:46 <ttx> the next question is whether we need to special-case servers
13:56:52 <ttx> vs. libraries
13:57:18 <ttx> currently we have that distinction in language (API servers, main deliverables, etc)
13:57:25 <ttx> but that doesn't exist in projects.yaml
13:57:29 <ttx> or anywhere else
13:57:35 <ttx> to map it to repositories
13:58:33 <dhellmann> what are you considering as a reason for needing to distinguish between them? knowing which script to run?
13:58:47 <ttx> I guess if we track all the "managed" work (included libraries as we handle tags for them) distinguishing netween libraries and servers is less needed
13:59:08 <ttx> I was trying to justify what ends up on the list of tracked things in that page
13:59:24 <dhellmann> and servers that have intermediate releases are sort of acting more like libraries in that sense, so those can probably use the same tools already
13:59:35 <dhellmann> change release_library.sh to release_semver.sh
13:59:44 <ttx> http://git.openstack.org/cgit/openstack-infra/puppet-releasestatus/commit/?id=f0d4a344aaa6dfbf55457d42ad9b065d79bc4d40
14:00:01 <ttx> I had a hard time coming up with that list yesterday, which is the cause for all those questions
14:00:26 <ttx> I ended up with "all servers we actually handle"
14:00:36 <ttx> which was a bit fuzzy
14:00:49 <dhellmann> we should start adding the libraries, too, I think. We have to start communicating better about things like deprecated options defined in libraries.
14:00:53 <dhellmann> config options, that is
14:01:28 <ttx> OK, so maybe I should just not distinguish between servers and libs in my initial bucket up there
14:01:31 <dhellmann> also things like the qpid driver being deprecated
14:01:49 <dhellmann> yeah, anything we manage seems like fair game to be added there
14:02:02 <ttx> the only thing that makes them different from intermediuary-released servers beiung the way we use LP pages
14:02:20 <ttx> and we could converge there
14:02:34 <ttx> heck we could even upload a tarball
14:02:35 <dhellmann> yeah, I think we probably should
14:02:45 <dhellmann> (converge)
14:03:01 <ttx> ok, I think we have food for thoughts and our hour is finished
14:03:05 <dhellmann> ok
14:03:14 <ttx> let's go back to our secret lair and see how next week looks like
14:03:25 <dhellmann> heh, sounds good
14:03:26 <ttx> #endmeeting