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