14:00:29 <dhellmann> #startmeeting releaseteam
14:00:29 <openstack> Meeting started Fri Sep 30 14:00:29 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <openstack> The meeting name has been set to 'releaseteam'
14:00:37 <EmilienM> o/
14:00:42 <dhellmann> courtesy ping: ttx, dims, fungi
14:00:42 <dims> o/
14:00:46 <ttx> o/
14:00:49 <fungi> the audience was getting restless, i see
14:01:00 <sigmavirus> o/
14:01:05 <dhellmann> this is week R-1 and our agenda is in the usual etherpad
14:01:06 <dhellmann> #link https://etherpad.openstack.org/p/newton-relmgt-tracking
14:01:40 <dhellmann> #topic projects needing attention
14:01:54 <dhellmann> things look good for the most part, though we have a few projects with unreleased changes in stable/newton
14:02:00 <dhellmann> #link http://paste.openstack.org/show/583626/
14:02:12 <dhellmann> ttx, you added this item, did you have specific thoughts on any of these?
14:02:34 <ttx> I was wondering about pinging PTLs on IRC to remind them on the deadline
14:02:46 <ttx> Same for the ones which have pending translations
14:03:07 <dhellmann> ok
14:03:13 <ttx> to reduce RCs on last week
14:03:20 <dhellmann> well, this is the last week, right?
14:03:33 <dims> that's what i was telling people dhellmann :)
14:03:37 <ttx> let's say to reduce exception pressure on last week
14:03:45 <dhellmann> ah
14:03:49 <dims> :)
14:04:14 <dhellmann> so we could do that, or we could tell people to plan on having patch releases
14:04:41 <dims> stevemar indicated that one pending translation is not really critical to do a rc3 for keystone
14:04:43 <ttx> I was thinking just a courtesy ping, not chasing them down
14:04:47 <dhellmann> ok
14:05:00 <ttx> can do a batch after meeting
14:05:00 <dims> ++ to courtesy ping
14:05:29 <dhellmann> yeah, I guess it's ok. I'm worried that we keep setting a precedent of reminding people to do things they should be paying attention to in the first place
14:05:43 <dhellmann> how about an email to the -dev list, with the projects tagged as well as [release]?
14:06:47 <ttx> I think they have been warned on the ML enough.. IRC pings allows to differentiate. Also less official
14:06:54 <ttx> the ML could set a precedent
14:06:59 <dhellmann> yeah, ok
14:07:10 <dhellmann> alright, so let's make a list then
14:07:13 <ttx> I'll do it so that it doesn't feel like it's a relmgt PTL duty
14:07:37 <ttx> Will ping ceilo, congress, senlinhorizon, zaqar
14:07:39 <dhellmann> I've already talked to stevemar about keystone and that translation patch is apparently removing some messages rather than adding any
14:07:45 <ttx> dims said stevemar is covered
14:07:50 <dhellmann> yeah
14:08:11 <ttx> I'll ping jd nowsince he is EU
14:08:22 <dhellmann> ok
14:09:10 <dhellmann> there are a couple of other projects called out in the agenda, including monasca and tripleo
14:09:19 <EmilienM> o/
14:09:22 <dhellmann> hi, EmilienM
14:09:23 <ttx> yeah, that's me reading the tracking sheet
14:09:29 <dhellmann> lack of branches?
14:09:35 <ttx> let me see again
14:09:49 <EmilienM> hi dhellmann, my question was about could we release an RC3 next week, we're still fixing critial bugs at this time
14:09:51 * ttx is quite sick today so not at 100%
14:10:03 <dhellmann> ttx: sorry to hear that. do you want me to handle those pings?
14:10:11 <ttx> no no, that sounds easy enough :)
14:10:19 <dhellmann> EmilienM : that's up next, stand by
14:10:26 <EmilienM> k
14:10:36 <ttx> yeah so monasca, no stable branch, no recent release
14:11:14 <dhellmann> I see no branches for monasca, solum, tripleo, & fuel
14:11:25 <dhellmann> the monasca release listed as their rc1 was  pretty recent
14:11:33 <EmilienM> no branch for tripleo? which project in specific?
14:11:39 <dhellmann> I didn't get a clear indication that they were ready for a branch, so I didn't create it
14:11:47 <dhellmann> EmilienM : https://docs.google.com/spreadsheets/d/1wy_YgMQ1MowE9Loztn6QAsMGOfVkVsqIQVdcIdrHAtI/edit#gid=2082157708
14:12:01 <dhellmann> EmilienM : looks like os-*-config
14:12:28 <dhellmann> I have some notes about "wait for rc2 to branch" but we either didn't branch or didn't record it
14:12:35 <dhellmann> I'll double check that after the meeting
14:12:37 <EmilienM> os-* don't have branches AFIK
14:12:40 <ttx> fuel is arguably trailing
14:12:47 <dhellmann> ttx: right
14:13:02 <EmilienM> or at least they never had branch before, so I didn't request for it
14:13:04 <dhellmann> I wasn't sure about those tripleo components, either, because of the late gate issues
14:13:23 <EmilienM> I've checked but AFIK all tripleo projects that we want branched are branched now
14:13:24 <dhellmann> EmilienM : ok, we can make those at any point, so I was just leaving them until I was sure someone wanted them
14:13:28 <dhellmann> cool
14:13:38 <ttx> I'm pretty sure some of those will just show up on Wednesday and ask for a release
14:13:51 <dhellmann> ttx: the trailing projects?
14:13:58 <ttx> no, solum/monasca
14:14:09 <dhellmann> oh, well, they'll be sad then
14:14:22 <dhellmann> no more intermediary releases before 10 Oct, right?
14:14:28 <dhellmann> after today, that is
14:14:34 <ttx> dhellmann: any reason why solum/monasca don't have stable ? They didn't ask ?
14:14:43 <dhellmann> ttx: right, they didn't confirm that they were ready
14:15:07 <ttx> dhellmann: unless they can point to some seriously embarassing regression
14:15:18 <dhellmann> ttx: of course, sure
14:15:31 <ttx> dhellmann: ok so plan there is just to cutr the branch Thursday when we make them the release ?
14:15:53 <ttx> solum seems to have a recent (~RC1) thing
14:16:02 <dhellmann> ttx: I had planned to wait for them to notice that they didn't have a branch and to ask for it
14:16:19 * dims afk for a little bit, promise to read scrollback
14:16:35 <dhellmann> I want to start encouraging them to get into the self-service mode, since we're planning to add branch requests to the deliverable files next cycle
14:16:36 <ttx> dhellmann: as long as we can include the latest in the "final" I guess we are good
14:16:58 <ttx> no absolute need to cut the stable branch
14:17:18 <dhellmann> right, we'll move ahead with releases as they are and deal with the stragglers' branches later
14:17:24 <ttx> ok, and monasca looks like reasonably similar, recently updated
14:17:50 <ttx> that leaves the os-* tripleO things which are a bit baffling
14:18:05 <ttx> (i.e. using RC while intermediary and no stable branch)
14:18:22 <ttx> but then my head hurts
14:18:28 <fungi> the outstanding stable/newton backports for the ossa i was worried about seemed to make it into cinder and glance rc2, so i'm satisfied
14:18:30 <EmilienM> what would you suggest? to change the release model?
14:18:32 <dhellmann> EmilienM : are those os-*-config projects ready for final releases next week, re-tagging the existing items?
14:18:47 <EmilienM> dhellmann: they are ready for final release.
14:18:49 <dhellmann> EmilienM : the version numbers and model need to sync up, yes
14:19:06 <dhellmann> ttx: what do you think about tagging those finals today, then?
14:19:15 <dhellmann> fungi : good, thanks
14:19:18 <sigmavirus> fungi: thanks for pinging about those btw (from glance's side)
14:19:40 <EmilienM> os-*-config are release:cycle-with-milestones
14:19:53 <EmilienM> does release:cycle-with-milestones require stable branches?
14:19:53 <ttx> are they?
14:20:04 <dhellmann> EmilienM : are they? maybe we imported them incorrectly into this sheet
14:20:17 <EmilienM> sounds like yes: https://governance.openstack.org/reference/tags/release_cycle-with-milestones.html#rationale
14:20:24 <dhellmann> so they are
14:20:30 <ttx> dhellmann: if they are intermediary, tagging a "final" today sounds good
14:20:38 <ttx> if milestones-driven, then RC track it is
14:20:44 <EmilienM> well, it's not clear to me in the governance link
14:20:46 <ttx> and retarg on Thusrday
14:20:50 <dhellmann> since they're milestone-based I'll fix the spreadsheet
14:21:05 <EmilienM> if whether or not release_cycle-with-milestones requires stable branching?
14:21:07 <ttx> dhellmann: should they already have their stable branch then ?
14:21:13 <ttx> EmilienM: it does, around RC1
14:21:14 <dhellmann> EmilienM : we expect *all* cycle-based projects to use stable branches
14:21:36 <EmilienM> ok, so let's create them
14:21:43 <dhellmann> ok, I will do that today using the most recent rc
14:21:57 <EmilienM> dhellmann: thank you and sorry for confusion
14:22:05 * EmilienM learning everyday :)
14:22:21 <dhellmann> EmilienM : np, we should have been more careful with version reviews early in the cycle
14:22:24 <dhellmann> we're learning, too :-)
14:22:24 <sigmavirus> EmilienM: count me in with you ;)
14:22:56 <dhellmann> EmilienM : you'll want to review those to make sure that any changes that have come in after the last rc are backported if you plan a newton update release
14:23:07 <EmilienM> dhellmann: ack
14:23:14 <EmilienM> dhellmann: I'll communicate with my team
14:23:30 <dhellmann> sounds good
14:23:45 <dhellmann> ttx, did I cover all of the projects with issues that you'd found?
14:24:00 <ttx> yes
14:24:07 <dhellmann> ok, moving on then
14:24:12 <dhellmann> #topic trailing project release candidates
14:24:26 <dhellmann> EmilienM had asked whether it was OK to have more release candidates for trailing projects between now and their final deadline
14:24:44 <dhellmann> my initial response was yes, but I wanted to talk it over and make sure I wasn't missing something
14:25:24 <dhellmann> thoughts?
14:25:57 <EmilienM> yes, we made our best to respect the deadlines but we still have critical bugs reported by our operators
14:26:10 <fungi> their integration test jobs will continue testing against master branches of other projects which have already released for the cycle, but that will be the case with or without additional rc tags
14:26:10 <EmilienM> ie: we have currently working hard on upgrades and ipv6
14:26:16 <dhellmann> sure, that's why we added the trailing release model
14:26:54 <fungi> or do the trailing projects already have stable/newton branches at this point?
14:26:56 <EmilienM> fungi: we have stable/newton jobs
14:26:57 <dhellmann> fungi : we do have branches for a lot of them
14:27:08 <EmilienM> fungi: tripleo included
14:27:08 <fungi> oh, okay, that solves for it then
14:27:19 <dhellmann> but that's a good point: we should not, in the future, delay branching the trailing projects
14:27:27 <EmilienM> so my request is to release RC2 by next Thursday
14:27:50 <EmilienM> we still have patches that will require backports (everything about upgrade for example)
14:27:58 <dhellmann> right
14:28:01 <EmilienM> RC3 sorry
14:28:07 <EmilienM> RC2 is already release (/me facepalm)
14:28:33 <dhellmann> we'll be tagging the final releases of the other projects thursday, early, so if we wait a bit and do the next rc for trailing projects later in the day that should be ok
14:28:53 <dhellmann> ideally we wouldn't do them the same day, but I don't want to rush you or do a release on friday
14:29:02 <EmilienM> ok I'll be online Thursday/Friday ready to release and help with it
14:29:12 <ttx> dhellmann: maybe say they should all have stable branches by release day
14:29:13 <ttx> ?
14:29:21 <EmilienM> I don't mind to release next Friday. It's all up to you
14:30:02 <dhellmann> ttx: I believe all of them do? we have some puppet deliverables listed that don't seem like they're going to be released at all this cycle, but the ones that have releases have branches
14:30:04 <EmilienM> ttx: I think that's fine, some people in our team are already working on ocata codebase. But other folks are still on newton
14:30:29 <EmilienM> dhellmann: re-puppet : no some modules are not production ready, we don't want to release them until they have functional tests.
14:30:34 <EmilienM> ie: puppet-congress, etc
14:30:51 <EmilienM> they are still WIP so no need to release them imho
14:30:53 <dhellmann> EmilienM : that's fine, I think we talked about that so I've just been ignoring those rows on the spreadsheet
14:31:35 <dhellmann> I think that's settled then
14:31:45 <dhellmann> #topic planning final release tasks
14:31:46 <EmilienM> so can we have an RC3 next week? https://goo.gl/At2xKh
14:31:53 <dhellmann> #undo
14:31:54 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f66f5197a10>
14:31:55 <dhellmann> EmilienM : yes
14:32:01 <EmilienM> I'm sure dhellmann can't resist to this picture.
14:32:13 <dhellmann> #info trailing projects can have additional release candidates between now and their final deadline
14:32:22 <dims> LOL nice one EmilienM
14:32:29 <dhellmann> aw
14:32:49 <dhellmann> now I'll get a reputation for being bribable with kitten pictures ;-)
14:32:54 <dhellmann> #topic planning final release tasks
14:33:00 <ttx> that was already public knowledge
14:33:03 <dhellmann> heh
14:33:11 <dims> :)
14:33:16 <dhellmann> I have a list of the tasks I think we need to do next week outlined in the R+0 task section of the etherpad
14:33:32 * ttx looks
14:33:42 <dhellmann> I plan to line up the release patch on wednesday so it is ready to go early thursday
14:34:13 <ttx> dhellmann: let me ask about the PR timing
14:34:29 <dhellmann> ttx: ok
14:34:46 <ttx> dhellmann: any preferred time ?
14:35:10 <dhellmann> ttx: well, I won't be in europe this time, so probably close to something like what they wanted last time
14:35:13 <ttx> traditionally 10am CT I think
14:35:22 <dhellmann> I have 14:00 UTC, which I think was 9 or 10 CT
14:35:48 <ttx> yeah, we can start at 14:00 so that it's done at 15:00UTC
14:35:49 <fungi> that's 9am cdt, yes
14:35:49 <dhellmann> but that was just a guess anyway
14:36:08 <ttx> not a big deal since people schedule their articles to go off at 00:01 anyway
14:36:24 <ttx> "it's out"-- no it's not
14:36:34 <dhellmann> time is hard
14:36:41 <sigmavirus> heh
14:37:01 <dhellmann> I also have a draft of the announcement linked there, and I'd appreciate any feedback on the wording
14:37:21 <dhellmann> it's copied from last time, with the additional piece of information that there are almost 200 components this cycle (thanks to EmilienM and his list of puppet modules)
14:37:22 <ttx> dhellmann: I'll let you know when they tell me
14:37:32 <ttx> but certainly 9/10am CT
14:37:56 <dhellmann> ttx: sounds good, thanks. and hour here or there isn't a big deal to me, since it's morning.
14:38:16 <ttx> no, as long as we are +-2h I think it's good enough
14:38:37 <dhellmann> so, the gerrit acl changes -- are those for thursday or friday?
14:39:01 <ttx> It's for Thursday after we prcessed release I'd say
14:39:08 <ttx> i.e. ASAP
14:39:10 <dhellmann> same for the release name
14:39:19 <dims> dhellmann : announcement looks good to me
14:39:21 <ttx> not a big deal if we miss by a few hours
14:39:39 <dhellmann> what I'm really worried about is whether we have all of the steps listed there, so if you think of something else we need to do please let me know
14:39:43 <dhellmann> dims : thanks
14:40:14 <dhellmann> oh, and thanks fungi, clarkb, & pabelanger for agreeing to be on standby while we do the tagging, in case anything goes wrong
14:40:17 <ttx> dhellmann: will do. I'd say that today I'm not feeling good enough for that kind of extra-lucidity
14:40:31 <ttx> It /looks/ sane
14:40:34 <dhellmann> ttx: it can wait until monday
14:40:45 <ttx> let me add that task
14:40:46 <fungi> happy to make sure all goes smoothly
14:40:54 <dhellmann> I pulled these from our PROCESS.rst file, so I'm pretty comfortable with it, but more eyes are better
14:41:12 <dims> :)
14:41:26 <dhellmann> moving on
14:41:39 <dhellmann> we talked about scheduling for the final release & announcement already
14:41:42 <dhellmann> #topic random fail
14:41:47 <dhellmann> http://lists.openstack.org/pipermail/release-job-failures/2016-September/000183.html
14:41:52 <dhellmann> #link http://lists.openstack.org/pipermail/release-job-failures/2016-September/000183.html
14:42:10 <dhellmann> the tarball job there failed in an odd way
14:42:11 <ttx> 200 ? wow
14:42:14 <dhellmann> #link http://logs.openstack.org/c0/c0010b425247fa75a0c69c9201629d8ad8c635c3/release/pyeclib-tarball-signing/25c1ff3/console.html
14:42:25 <dhellmann> ttx: "ls deliverables/newton | wc -l"
14:42:45 <ttx> dhellmann: should we say "deliverables" instead of "components" ?
14:42:55 <dhellmann> probably
14:43:16 <ttx> also should remove the trailing from the count
14:43:35 <dhellmann> oh, that's a good point
14:43:39 <dhellmann> I'll figure out the right number
14:44:04 <dhellmann> sorry, EmilienM  :-(
14:44:34 <dhellmann> so on this failure, have we seen this before for pyeclib? or anything else?
14:45:04 <ttx> dhellmann: maybe say "for the x services and y other components that make up the release" or something like this
14:45:20 <dhellmann> ttx: sure
14:45:27 <ttx> I fear a crazy number will just reinforce the "Big Tent is insane!11!" hate
14:45:33 <sigmavirus> dhellmann: pyeclib doesn't have setup.cfg?
14:45:34 <ttx> it's not that many services
14:45:41 <ttx> it's just plenty of libs and packages
14:45:46 <sigmavirus> it's not using pbr dhellmann
14:45:56 <dhellmann> sigmavirus : good eyes
14:46:02 <ttx> (31 services)
14:46:49 <ttx> so 31 services and ~130 other components
14:46:57 * dhellmann wonders if pyeclib is an official project
14:47:09 <sigmavirus> dhellmann: do all official projects need to use pbr?
14:47:12 <dhellmann> it's not on the swift team list
14:47:15 <sigmavirus> It has C extensions in-tree
14:47:33 <dhellmann> sigmavirus : we expect python projects to follow the conventions supported by the release and infra teams
14:47:47 <sigmavirus> I know pbr can handle those but I don't think there's sufficient prior art for something that seems to have not been developed in openstack from the start to have been comfortable using it
14:47:57 <sigmavirus> dhellmann: makes sense
14:47:59 <ttx> I propsoed alternate wording on the etherpad
14:48:18 <sigmavirus> dhellmann: just looks like it started outside openstack and is now maintained here
14:48:20 <dhellmann> ttx: looks good
14:48:21 <sigmavirus> maybe hasn't been updated
14:48:28 <fungi> pyeclib was adopted from elsewhere, yeag
14:48:29 <dhellmann> sigmavirus : that's quite possible
14:48:30 <fungi> yeah
14:48:41 <anteaya> its only mention is here as a deb repo: http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n4915
14:48:45 <dhellmann> ok, so the fix is for them to update their packaging metadata and then tag another release, I guess?
14:48:48 <ttx> dhellmann: not in governance
14:49:00 <ttx> (pyeclib)
14:49:16 <dhellmann> or to manage publishing their own releases if they don't want to do that, I suppose
14:49:45 <dhellmann> since, as ttx points out, it's not a governed project I'm not too concerned about it, until/unless they ask for help
14:49:54 <ttx> dhellmann: so we should not sign it
14:50:09 <ttx> (imho)
14:50:30 <ttx> but yes, not top issue
14:50:32 <dhellmann> sign the tag? or sign the tarball?
14:50:41 <sigmavirus> dhellmann: both?
14:50:49 <sigmavirus> i suspect they'll sign their own tag
14:50:50 <dhellmann> fungi : thoughts? ^^
14:51:27 <fungi> they made a release request?
14:51:31 <dhellmann> yeah, I don't have a problem skipping the tag signing, but I think we should probably sign the artifact
14:51:44 <dhellmann> no, we get notified of failures regardless of whether they go through the releases repo
14:51:49 <sigmavirus> aha
14:51:51 <fungi> oh, got it
14:51:59 <ttx> fungi: no
14:52:46 <fungi> yeah, i'll see if i can track one of its maintainers down to either fix their packaging or remove the release jobs
14:53:04 <dhellmann> fungi : thanks
14:53:28 <fungi> just be aware that having a mailsink for a given pipeline means that there are always going to be unofficial projects with broken jobs reporting to it
14:53:29 <dhellmann> #topic open discussion
14:53:35 <dhellmann> #undo
14:53:36 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f66f5d1c090>
14:53:52 <dhellmann> fungi : yeah, that's not a problem.
14:54:10 <dhellmann> I don't mind helping them out, if they want it. I was more concerned that the failure looked odd
14:54:13 <ttx> yeah, just raised it because it's the only fail that actually prevented an upload
14:54:21 <dhellmann> right
14:54:26 <ttx> all the others are wheel SKIPs
14:55:05 <dhellmann> yeah, those are bothersome because they're so frequent, but they don't seem to actually break anything
14:55:10 <dhellmann> #topic open discussion
14:55:20 <rosmaita> two quick items from me about glance
14:55:21 <dhellmann> that's it for the formal agenda, does anyone have anything else to raise this week?
14:55:25 <dhellmann> hi, rosmaita
14:55:31 <rosmaita> first, i would like to introduce sigmavirus (Ian Cordasco) as the glance "release czar" (basically ttx's "release steward" with a more authoritative-sounding title)
14:55:41 <rosmaita> i'm really happy that ian has agreed to be glance release czar, because he will most likely prevent me from making the kind of mistake in ocata that i am about to ask you about
14:55:50 <rosmaita> second item
14:55:55 <ttx> Release ADmiral
14:56:02 <sigmavirus> "RAD"?
14:56:02 <rosmaita> :)
14:56:12 * dhellmann pictures sigmavirus with epaulets
14:56:12 <rosmaita> just not "rear admiral"
14:56:14 <ttx> The RAD.
14:56:16 <rosmaita> question about whether docs are "critical" ... here is some quick background (i will type fast)
14:56:25 <rosmaita> as you know, the api-ref was moved out of docs and into the source code tree for each project this cycle
14:56:32 <rosmaita> the api-ref on openstack.org is published from master
14:56:43 <rosmaita> so for glance, i planned to make sure all revisions for newton were merged into master before 6 Oct ... but did not make it a priority for RC time
14:56:53 <rosmaita> thus we have an inaccurate api-ref in the stable/newton source tree
14:57:01 <rosmaita> and you can see where i am going with this ... should we backport the revisions in master into stable/newton?  this would mean RC3 for us, and a PITA for y'all
14:57:11 <rosmaita> what is your opinion? (a) backport and new RC? or, (b) not critical, leave stable/newton alone (we don't seem to have any new translations, so unless someone discovers a bad bug over the weekend, the docs update would be the only thing in RC3)
14:57:26 * rosmaita gives his fingers a rest
14:57:31 <dhellmann> if the guide is always published from master, it seems like you can backport the changes and let them be part of a point release
14:57:59 <sigmavirus> dhellmann: yeah that's what I was trending towards and hoping the other glance-stable-maintainers would agree
14:58:01 <dhellmann> unless we know someone else is using the stable branch to ship docs?
14:58:09 <rosmaita> i would hope not
14:58:28 <rosmaita> the api-ref is new in-tree, so hopefully no one is looking for it yet
14:58:48 <dhellmann> yeah
14:59:04 <dhellmann> let's be cautious this time, and if it causes problems they'll be fixed by that point release
14:59:11 <rosmaita> just to make sure i understand, the idea is leave RC2 as-is, and update stable/newton post-release to 13.0.1 or something
14:59:18 <dhellmann> so, no new rc just for api doc changes
14:59:23 <dhellmann> that's right
14:59:26 <rosmaita> ok, cool
14:59:29 <rosmaita> ty!
15:00:01 <dhellmann> rosmaita : would you mind brining this up on the ML so we spread the word about the plan?
15:00:08 <rosmaita> sure
15:00:12 <dhellmann> rosmaita : thanks
15:00:15 <rosmaita> sigmavirus had already suggested that
15:00:23 <dhellmann> ok, our time is up here, so we can move to #openstack-release if we have more to discuss
15:00:26 <dhellmann> cool
15:00:27 <rosmaita> he's already earning czar-level pay
15:00:28 <ttx> dhellmann: thx!
15:00:31 <dhellmann> heh
15:00:34 <sigmavirus> rosmaita: uh, no
15:00:35 <dhellmann> thanks everyone!
15:00:35 <sigmavirus> lol
15:00:37 <sigmavirus> o/
15:00:43 <dhellmann> #endmeeting