14:34:46 <dhellmann> #startmeeting releaseteam
14:34:47 <openstack> Meeting started Fri Nov 27 14:34:46 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:34:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:34:51 <openstack> The meeting name has been set to 'releaseteam'
14:34:54 <ttx_> so I was saying...
14:35:09 <dhellmann> we were talking about how to announce the milestone tags
14:35:12 <ttx_> My question about mitaka-1 is... should we land the current patchseries now ? How much do we need for next week ?
14:35:24 <dhellmann> for the tools?
14:35:47 <ttx_> yeah, the patchseries in tools handles the tagging and launchpad part
14:35:47 <dhellmann> I used your updated release script for a release last week, and made some changes as a result
14:36:01 <dhellmann> I think if we land all of those things on monday we'll be in good shape for the week
14:36:06 <ttx_> but doesn't do anythign about announcement
14:36:14 <dhellmann> I'm going to work on the announce script monday, too
14:36:17 <dhellmann> I ran out of time yesterday
14:36:21 <dhellmann> er, wednesday
14:36:22 <ttx_> ok
14:36:38 <ttx_> dhellmann: how do you want to proceed for announcements ?
14:36:44 <dhellmann> how much do we want the announcements to include?
14:37:02 <dhellmann> do we want the full reno-based release notes? or just a short "we've tagged a beta release" message?
14:37:30 <ttx_> I'm fine with a collective "we did it"
14:37:37 <ttx_> since it's a b1
14:37:57 <dhellmann> ok, and if we add the release notes links to the releases page we can refer folks there to get to the notes
14:38:14 <dhellmann> you had a comment on the formatting for that, and I'll try to address that monday, too
14:38:14 <ttx_> maybe we can do a collective announcement by hand and then script it before b2
14:38:17 <dhellmann> it shouldn't be too hard to fix
14:38:54 <ttx_> It's just that if we merge the current patchseries it breaks things for libs, no ?
14:39:02 * ttx_ looks
14:39:10 <dhellmann> ttx: no, the libs are no longer supposed to update launchpad either
14:39:28 <ttx_> but they are supposed to be announced, and I removed that from the release script
14:39:34 <dhellmann> oh, yeah, I did that by hand
14:40:01 <dhellmann> and I'll have that resolved monday, one way or another
14:40:11 <ttx_> so if we merge the current series we lose that (until we write the other script that picks that up)
14:40:14 <ttx_> ok
14:40:19 <dhellmann> the hard part is actually figuring out what the previous release was, and I think I have that
14:40:19 <ttx_> I guess we can wait until Monday
14:41:30 <dhellmann> k
14:41:45 <dhellmann> is there anything else to discuss about the milestone?
14:41:46 <ttx_> I just wanted to make sure we don't need anything more
14:42:13 <ttx_> I'll add to the doc and see "make a manual announcement once all m1 is done
14:42:21 <dhellmann> k
14:42:24 <ttx_> and add, I mean
14:42:39 <ttx_> and will try to test the whole thing
14:42:43 <dhellmann> I'll see if I can throw together something to produce a list of projects and versions with links to the release notes, based on the deliverable file contents
14:43:44 <dhellmann> ok, we had a couple of other topics on the agenda
14:43:45 <dhellmann> #topic not using reno for libraries
14:44:06 <dhellmann> after talking with dims and harlowja last week, and seeing some comments from other teams, I'm not sure about pushing the use of reno for release notes
14:44:19 <dhellmann> we do need a way to publish release notes that affect deployers,  like configuration options changing
14:44:23 <ttx_> specifically for libs ?
14:44:26 <dhellmann> but I'm not sure how many of those we actually have
14:44:28 <dhellmann> yes, just for libs
14:44:51 <ttx_> so what's the main pushback about ? More work ?
14:45:05 <dhellmann> yes, having to do something by hand they were getting automatically before
14:45:24 <dhellmann> otoh, we have to do something for deployer-facing changes
14:45:55 <dhellmann> so I think we need more discussion of that on the ML before we require it, to make sure everyone understands
14:46:07 <ttx_> what if they had reno but weren't using it 99% of the time, and we would publish the git log and diffstats as usual
14:46:19 <dhellmann> I think that would work
14:46:30 <ttx_> i.e. add reno paragraphs only if those were added
14:46:32 <dhellmann> the announce script could look for a configuration file in the repo or something
14:46:58 <dhellmann> or it could ignore reno report failures, and assume it's present
14:47:01 <ttx_> by default it would do the exact same thing as before, but the day they want to add something to reno it's ready to pick up that part
14:47:07 <dhellmann> right
14:47:24 <dhellmann> although it would be nice to have the same script work for libs and services, and we don't want the git log stuff for services
14:47:35 <ttx_> because as you said, while deployer facing chnages are not that frequent, it's good to communicate them more prominently
14:47:49 <dhellmann> right, libs have 2 audiences for different types of release information
14:48:02 <ttx_> could be some option in the releases yaml, I guess. Include-log
14:48:31 <dhellmann> we could also look at the type: tag on the repo
14:48:35 <ttx_> oh, ttx is back
14:48:47 <ttx_> ttx: o/
14:48:54 <dhellmann> hmm, the bot changed the topic back
14:49:03 * dhellmann wonders what the logs from this meeting are going to look like
14:49:16 <ttx> ttx_: o/
14:49:25 * dhellmann watches ttx wave to himself
14:49:29 <ttx_> bad, I'm sure
14:50:13 <dhellmann> yeah, I'll sort out the notes after we're done
14:50:21 <dhellmann> #topic not using reno for libraries
14:50:26 <dhellmann> hey, there's the bot
14:50:39 <ttx_> fwiw ttx is lagghing horribly, I'll stay on this side of my split personality
14:51:18 <ttx_> so yeah, I think libs should use reno, but should degrade gracefully to current situation if reno is not used
14:51:24 <dhellmann> ok, so it seems like we agree that the announce script should allow lib projects to not have reno, but that we want to encourage it where it makes sense. we also should not send git log info for announcements of server projects
14:51:35 <ttx_> or that
14:51:39 <dhellmann> hmm, I thought we'd use reno *and* git logs for libs
14:51:44 <ttx_> yes
14:51:45 <dhellmann> k
14:51:58 <ttx_> you want it to be additive, not replacement
14:52:09 <dhellmann> I'll take that into account when I start on that script monday
14:52:14 <dhellmann> right
14:52:21 <dhellmann> ok, a few more minutes, one more quick topic
14:52:23 <dhellmann> #topic moving meeting to #openstack-meeting-cp room
14:52:47 <ttx_> I'm not sure. The goal of the channel wasn't to have all horizontal teams mving to it
14:52:49 <dhellmann> now that we have the new cross-project room, does it make sense to move this meeting there? I'm not sure it buys us much, but I thought I'd ask.
14:53:03 <dhellmann> yeah, that wasn't 100% clear
14:53:10 <ttx_> just to have a place to have the cross-project specs discussions
14:53:14 <dhellmann> I'd be completely happy to just stay here
14:53:18 <dhellmann> ah, ok
14:53:21 <ttx_> let's stay here for the time being
14:53:26 <dhellmann> cool, so not moving
14:53:30 <ttx_> and see how it goes
14:53:33 <dhellmann> #topic open discussion
14:53:38 <dhellmann> anything else before our window closes?
14:54:03 <ttx_> nope
14:54:16 <dhellmann> lk
14:54:17 <dhellmann> ok
14:54:36 <dhellmann> while we were having issues, I sent the instruction email for next week to the -dev list
14:54:51 <dhellmann> now I'll go try to make sense of the meeting logs :-)
14:54:55 <dhellmann> thanks, ttx, tty monday
14:55:06 <ttx_> ack
14:55:08 <dhellmann> #endmeeting