16:00:01 <smcginnis> #startmeeting releaseteam
16:00:03 <openstack> Meeting started Thu Mar  7 16:00:01 2019 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'releaseteam'
16:00:08 <smcginnis> evrardjp: Quick!
16:00:15 <smcginnis> Ping list: smcginnis ttx dhellmann diablo_rojo hberaud evrardjp fungi armstrong
16:00:18 <evrardjp> :)
16:00:23 <smcginnis> #link https://etherpad.openstack.org/p/stein-relmgt-tracking Agenda
16:00:36 <smcginnis> Waay down around line 387 now.
16:00:55 <smcginnis> Thank you as usual to ttx for getting an agenda together there.
16:01:13 <smcginnis> At least I assume it was ttx. :)
16:01:27 <fungi> aloha
16:01:43 <smcginnis> Morning fungi
16:01:59 <ttx> o/
16:02:10 <ttx> yes I'm to blame
16:02:16 <evrardjp> fungi: always sending me a holiday vibe
16:02:50 <smcginnis> #topic Queens Tripleo release
16:03:15 <smcginnis> README issued blocked on being able to merge to stable.
16:03:17 <smcginnis> #link https://review.openstack.org/#/c/640023/
16:03:52 <diablo_rojo> o/
16:04:33 <smcginnis> I wasn't aware of these. I suppose they could switch over to noop, get this merged, then switch mack and figure things out.
16:04:35 <ttx> yeah they are blocked so I wanted to discuss a solution there
16:04:45 <smcginnis> ttx: Did you have something in mind?
16:05:19 <ttx> Looks like for some reason the jobs were disabled on Queens
16:05:38 <ttx> and now that they are trying to reenable them to get this technical change merged they see they are broken
16:05:58 <ttx> so I was windering if we should just not force-merge them, since it's extremely likely to be a one-off
16:06:37 <ttx> maybe fungi has an opinion on that :)
16:06:48 <fungi> yeah, i'm trying to digest the problem
16:06:48 * evrardjp takes popcorn
16:06:52 <smcginnis> Seems like they should get things fixed, but that would work to get things going for now.
16:07:14 <ttx> I guess they could just set noop instead of the set of failing jobs
16:07:26 <evrardjp> ofc
16:07:27 <fungi> they want to tag a new point release of tie from stable/queens?
16:07:48 <evrardjp> or just remove openstack-python-jobs
16:07:55 <ttx> I think they want to do a new tripleo release, and that includes some repo that they are no longer updating
16:07:56 <fungi> and their python 2.7 unit tests no longer work on that branch?
16:08:16 <ttx> except that our validation is now catching README formatting, so they kind of need to fix that
16:08:44 <ttx> so they are trying to, but they get no job to match, and adding the ones previously defined kinda fails
16:09:19 <ttx> Haven't gone deeper in the rabbit hole as to WHY those long-dead jobs tdo not work when reanimated
16:09:25 <fungi> yeah, i don't know how to set the no-op job just for specific branches of a repository but i can ask a few others
16:09:51 <evrardjp> sorry to be selfish here
16:09:55 <ttx> I feel like we should just force-merge it as it's really the only thing that will land there
16:09:58 <smcginnis> Something seems off about wanting to release something that can't pass unit tests. Really feels like they should fix things first.
16:10:07 <ttx> rather than spend time "fixing" it
16:10:08 <evrardjp> but shouldn't the team fix it in a one off to do this?
16:10:21 <smcginnis> And really seems like an issue for that team to figure out. Not really a release issue.
16:10:38 <evrardjp> that's what I meant -- they are in charge of their destiny?
16:10:39 <fungi> skimming the job log, it looks like some specific unit tests in there are failing
16:10:52 <ttx> That said, yes it's a bit weird tat they would want to do a release for something they can no longer fully test
16:11:03 <evrardjp> yup -- TestOsSvcDaemon.test_dir_only_upstart or something
16:11:11 <fungi> so maybe an easy suggestion is that they skip those specific unit tests in their py27 job
16:11:11 <smcginnis> They could also drop that repo from the release request and get everything else out.
16:11:32 <evrardjp> I think they should just fix it
16:11:33 <fungi> if they're not maintaining it, why does it need a new point release anyway?
16:11:36 <ttx> but then the deliverable will appear incomplete
16:11:46 <evrardjp> if you release it, it sends a message, right?
16:11:48 <ttx> fungi: yeah that is the point I raised just above
16:12:13 <fungi> but also, if they're not maintainind some particular repository in a deliverable and maintaining others, then it's not the same deliverable is it?
16:12:19 <ttx> happy with any outcome really -- we just need to tell them the best way out
16:12:29 <smcginnis> Do "we"?
16:12:54 <fungi> we can certainly present them with some of the options we came up with, but as to which is "best" that's likely up to them to decide
16:13:08 <evrardjp> fungi: ++
16:13:20 <evrardjp> we could also recommend what we consider best
16:13:28 <evrardjp> from our perspective
16:13:33 <fungi> jaosorior, as ptl, can also just read the above for our list of suggestions
16:13:38 <ttx> ok, if no easy solution let's not spend the whole meeting on this
16:13:38 <evrardjp> but then they take the decision :)
16:13:50 <evrardjp> ttx: agreed
16:13:51 <smcginnis> I agree. We can give suggestions as a group of people who care, but I don't think this is anything on the release team to sort out.
16:13:56 <ttx> and schedule a discussion with jaosorior to walk through it
16:14:38 <smcginnis> Any more on this topic?
16:14:42 <ttx> nope
16:14:51 <smcginnis> #topic Review R-5 week tasks
16:15:13 <ttx> I see two open tasks
16:15:27 <ttx> Generate release requests... (diablo_rojo and evrardjp)
16:15:30 <smcginnis> The first I can include in the countdown email.
16:15:38 <ttx> Freeze changes... (prometheanfire)
16:15:42 <smcginnis> Oh, looking at next week's tasks.
16:16:03 <ttx> smcginnis: that's next topic :)
16:16:12 <smcginnis> I believe diablo_rojo is ready to go on those release requests.
16:16:20 <diablo_rojo> smcginnis, correct
16:16:35 <evrardjp> mmm
16:16:42 <diablo_rojo> just regenerated the list and put it in the etherpad
16:16:44 <evrardjp> I think ttx has an opinion on this
16:16:47 <smcginnis> Thanks diablo_rojo and evrardjp for going through getting ready for that last week.
16:16:48 <diablo_rojo> its the same as it was
16:17:06 <diablo_rojo> I had already accidentally pushed the pankoclient patch
16:17:25 <ttx> I did record my opinion at https://review.openstack.org/#/c/640867/
16:17:27 * dhellmann slips into the back of the room late
16:17:38 <evrardjp> ttx: beat me to it :)
16:17:52 <ttx> i.e. we should release libraries that have not been released since milestone-2
16:18:04 <ttx> that is what we said we'd do
16:18:29 <ttx> and announced in email at the start of the cycle
16:18:44 <smcginnis> Right, we stated we would release c-w-i libs at each milestone.
16:18:51 <smcginnis> As long as there was something to release.
16:18:51 <ttx> Regarding tooling ISTR we had a magic CLI for that... dhellmann ?
16:18:52 <evrardjp> then yes somethign might have slipped through the cracks then
16:19:09 <smcginnis> But we also need to release the ones that didn't have anything to release previously so we have a branching point.
16:19:18 <ttx> smcginnis: and as long as they were not released otherwise in that same timeframe
16:19:30 <smcginnis> ++
16:20:20 <dhellmann> we have propose-library-branches
16:20:36 <dhellmann> and propose-final-releases but I don't know if that works for just libraries; I think that's about RC->final transition
16:20:51 <ttx> but not list-deliverables --unreleased-since <date>
16:21:08 <smcginnis> No scripts that will generate the release requests, but can at least tell us what has not been released.
16:21:34 <evrardjp> smcginnis: I didn't think we had something based on date.
16:21:42 <dhellmann> ah, no, not based on date
16:21:45 <ttx> fwiw that same script is supposed to help at milestone-1 and milestone-2 too :)
16:21:47 <evrardjp> smcginnis: problem is that we can't presume the release anymore
16:21:48 <dhellmann> that would be a good tool to have, though
16:22:05 <evrardjp> because ppl are not forced to create for milestone x anymore
16:22:14 <evrardjp> if I understood correctly
16:22:15 <dhellmann> I think I expected us to just use list_library_unreleased_changes.sh
16:22:28 <ttx> dhellmann: i mean, we'd really be grateful if that script existed, right
16:22:29 <dhellmann> anything that has changes needs to be released, including if they are just for tests
16:22:41 <dhellmann> ttx: I will buy the author a beer
16:22:43 <smcginnis> dhellmann: ++
16:22:50 <evrardjp> ttx: wow that wink crossed the oceans.
16:23:10 <ttx> dhellmann: I will buy the author a glass of wine.
16:23:14 <evrardjp> oh wait I have the impression this will backfire
16:23:33 <dhellmann> that escalated quickly
16:23:43 <evrardjp> :)
16:24:08 <smcginnis> So we have two things. Ones that haven't done any release yet that we can get with --unreleased, but that would also be included (presumable) in list_library_unreleased_changes.sh.
16:24:09 <evrardjp> dhellmann: want me to help there -- I think I would like to spend time on tooling, to refresh my knowledge, and clean what's not required if we can
16:24:20 <evrardjp> sorry wrongly phrased
16:24:25 <dhellmann> smcginnis : maybe not, if they haven't landed any changes
16:24:28 <evrardjp> dhellmann: do you want me to help there?
16:24:31 <ttx> It's also fine to generate them manually for this tmie, to see what's expected
16:24:31 <smcginnis> evrardjp: That would be great. It could use some attention I'm sure.
16:24:50 <smcginnis> dhellmann: True, there might be a few outside of that venn diagram overlap.
16:24:59 <evrardjp> ttx: probably best, because I am not sure when I will have time on this
16:25:10 <dhellmann> evrardjp : I'm not going to have time to do it, but I would be able to advise a bit
16:25:10 <openstackgerrit> Eric Fried proposed openstack/releases master: Release python-novaclient 13.0.0  https://review.openstack.org/641678
16:25:11 <dhellmann> evrardjp : so if you want to own it that would be great
16:25:34 <dhellmann> generating the actual releases could be scripted by calling new-release repeatedly once there is a list of the things that needs the releases
16:25:38 <smcginnis> You could do it manually for now and make sure the necessary steps are written down. Then at some point use that documentation to automate.
16:25:59 <dhellmann> if you start with the ones that are completely unreleased then it will make looking at the output of list_library_unreleased_changes.sh less of a chore
16:26:07 <evrardjp> dhellmann: I think that's what in my pseudo code in my patch
16:26:31 <dhellmann> ++
16:26:48 <diablo_rojo> I will get the patches for unreleased libs up today for you evrardjp
16:26:49 <evrardjp> but does list_library_unreleased_changes know about milestones?
16:27:02 <ttx> ok, let's move on --- I wrote down that evrardjp and diablo_rojo would work to generate those manually
16:27:08 <coreycb> hi all, does anyone know how i'd go about getting a 2.3.1 release of ldappool for stable/rocky? since it's an independent deliverable it's not obvious to me what is needed. https://github.com/openstack/releases/blob/master/deliverables/_independent/ldappool.yaml
16:27:11 <evrardjp> lgtm ttx
16:27:18 <evrardjp> diablo_rojo: we'll do this together :)
16:27:36 <ttx> the other item -- I haven't heard of prometheanfire this week
16:27:37 <evrardjp> I am just thinking of the next cycle at the same time :p
16:27:38 <evrardjp> anyway
16:27:47 <smcginnis> evrardjp: No, but if you get ones that haven't released at all, then any others that have changes that have not been released can be released.
16:27:56 <diablo_rojo> evrardjp, sounds good to me
16:28:17 <smcginnis> coreycb: It would not be for rocky since it's independent.
16:28:20 <ttx> but since the deadline is not there yet, I don't think we need to organize search and rescue just yet
16:28:30 <evrardjp> smcginnis: I didn't know we had the tooling for the ones with changes unreleased. That script name makes more sense to me know
16:28:35 <evrardjp> now*
16:28:39 <smcginnis> ;)
16:28:54 <smcginnis> OK, let's move on and we can work through any more details out of meeting.
16:28:59 <smcginnis> #topic Library freeze exceptions
16:29:08 <coreycb> smcginnis: ok. is it possible for me to update upper-constraints for stable/rocky ldappool?
16:29:25 <smcginnis> We did release octavia-lib today.
16:29:31 <ttx> yeah I spotted a lib release that was post-freeze... but it's bugfix enough I think
16:29:33 <smcginnis> They had issues that required a new release.
16:29:52 <ttx> happy to approve if everyone is happy with it
16:30:03 <ttx> oh it's done
16:30:07 <ttx> next topic :)
16:30:16 <smcginnis> I figured we would get that in the requirements update review if prometheanfire wanted an official FFE on that.
16:30:21 <ttx> Any missing library release ?
16:30:31 * coreycb apologizes for interrupting a meeting
16:30:50 <smcginnis> coreycb: No worries, sorry.
16:30:53 <ttx> or did we cover them all last week ?
16:31:09 <smcginnis> I believe we got all the libs, but we should double check that.
16:32:38 <ttx> os-client-config is the only one that shows as completely unreleased
16:33:11 <smcginnis> I think I had asked Monty about that one, but not sure if we got an answer.
16:33:44 <ttx> the others might not be recent (i.e. released since milestone-2)
16:34:08 <ttx> pycadf, shade had a single release
16:34:08 <fungi> mordred is around, i think
16:34:23 <smcginnis> Hmm, I see os-brick changes that should have gone out.
16:34:24 <mordred> what did I do?
16:34:29 <mordred> oh. poo. one sec
16:34:34 <dhellmann> os-client-config has a fair number of changes, including test job stuff
16:35:04 <ttx> same for automaton blazar-nova ceilometermiddleware cliff debtcollector kuryr mistral-lib mox3 os-acc
16:35:16 <mordred> yeah. sorry - we should likely cut a shade release
16:35:24 <ttx> those had a single release in stein ^
16:35:35 <ttx> which might or might not be recent
16:35:42 * ttx manually checks
16:36:04 <ttx> pycadf - 5 weeks ago
16:36:27 <openstackgerrit> Monty Taylor proposed openstack/releases master: Release 1.31.0 of shade  https://review.openstack.org/641716
16:36:55 <ttx> automaton = 6 days ago
16:37:14 <ttx> blazar-nova = 6 days ago
16:37:40 <fungi> mordred: the bigger question was around os-client-config
16:37:41 <ttx> same for ceilometermiddleware
16:37:54 <ttx> cliff - 4 months ago
16:37:57 <mordred> yeah - it's mostly test fixes - there's one patch that might be release worthy
16:38:14 <dhellmann> mordred : at this point, we want a release so when we branch those test fixes end up in your stable branch
16:38:17 <ttx> debtcollector - 7 days
16:38:26 <mordred> dhellmann: ++
16:38:31 <ttx> kuryr - 7 weeks
16:38:40 <dhellmann> so anything with any unreleased patches of any type should be released
16:38:52 <ttx> mistral-lib - 6 days
16:39:02 <ttx> mox3 - 7 days
16:39:08 <dhellmann> s/anything/any library/
16:39:19 <ttx> os-acc - 4 months
16:39:52 <openstackgerrit> Monty Taylor proposed openstack/releases master: Release 1.32.0 of os-client-config  https://review.openstack.org/641721
16:39:53 <dhellmann> it sounds like we have a lot of tags to generate
16:39:54 <ttx> I only checked those who released only once in the cycle as good candidates
16:40:03 <mordred> there ya go - sorry about that
16:40:32 <ttx> I'd say kuryr, cliff, and os-acc might need a refresh
16:40:56 <ttx> the others should be "fresh enough"
16:41:11 <smcginnis> We must need better documentation on generating those lib releases. The ones 6 days ago must have been picked up by the script. Not sure why the older ones were not though.
16:42:07 <dhellmann> the only change in kuryr is to add the python 3.7 job
16:42:26 <ttx> ok so the one release they have is good enough
16:42:39 <dhellmann> cliff has a lower-constraints template change, we should probably tag that
16:42:43 <dhellmann> os-acc has no changes
16:43:00 <ttx> dhellmann: can you generate the cliff release req?
16:43:05 <evrardjp> smcginnis: I agree
16:43:08 <dhellmann> sure
16:43:17 <ttx> smcginnis: yes we need a tool
16:43:30 <ttx> in the mean time this manual checking will do
16:43:50 <openstackgerrit> Doug Hellmann proposed openstack/releases master: cliff 2.14.1  https://review.openstack.org/641722
16:45:17 <ttx> ok all set
16:45:25 <smcginnis> Thanks!
16:45:31 <openstackgerrit> Kendall Nelson proposed openstack/releases master: Release python-aodhclient 1.2.0  https://review.openstack.org/640870
16:45:34 <smcginnis> #topic Client library freeze
16:45:54 <smcginnis> So still a few with no releases.
16:46:01 <smcginnis> We have several hours to go yet though.
16:46:23 <ttx> those are supposed to be caught by the task we already talked about
16:46:59 <ttx> Maybe y'all can use the etherpad as a tracking mechanism as you go through them manually
16:47:11 <ttx> that way we can play too
16:47:22 <smcginnis> Well, maybe that's an opportunity for more documention. We need need to capture the non-client lib ones at that deadline, then wait until end of today for the client lib ones.
16:48:28 <dhellmann> unreleased changes in client libraries: http://paste.openstack.org/show/747419/
16:48:29 <smcginnis> So really we need to rerun this client list tomorrow morning and see what ultimately missed today's deadline.
16:48:45 <ttx> ++
16:49:58 <smcginnis> evrardjp, diablo_rojo: Are you two on that task? Tomorrow get the final list and propose releases for any client libs that missed?
16:50:14 <diablo_rojo> smcginnis, yep I got it
16:50:19 <smcginnis> ++ Thanks!
16:50:26 <evrardjp> thanks diablo_rojo
16:50:37 <smcginnis> Overall I think it doesn't look too bad so far.
16:50:44 <diablo_rojo> Only 6
16:50:52 <smcginnis> We've seen worse. ;)
16:51:04 <smcginnis> #topic Cycle highlights collection
16:51:16 <diablo_rojo> I have an email drafted ready to send
16:51:36 <smcginnis> Excellent
16:51:44 <smcginnis> I had a blurb in the last countdown.
16:51:46 <diablo_rojo> I can click the button whenever
16:52:05 <diablo_rojo> I took from you original introduction to remnind folks of the importance and how to
16:52:09 <smcginnis> If you want to send that now, I can add a reference to that in the countdown email I send out to try to increase odds someone reads them.
16:52:16 <diablo_rojo> Can do
16:52:35 <diablo_rojo> Sent
16:52:47 <smcginnis> Great, I'll grab the link and add it.
16:53:11 <smcginnis> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003597.html
16:53:28 <smcginnis> #topic Forum brainstorming
16:53:52 <ttx> I was wondering if we wanted to submit anything
16:54:04 <ttx> it closes tomorrow-ish (or was it extended ?)
16:54:29 <smcginnis> Ben was going to submit a PTL feedback session that we had talked about piggybacking on to get release process change feedback.
16:54:41 <smcginnis> I didn't have anything else that I could think of needing.
16:54:48 <ttx> ++
16:55:00 <diablo_rojo> smcginnis, extended till the 10th
16:55:13 <smcginnis> OK, great.
16:55:26 <smcginnis> Anyone have any Forum appropriate release topics in mind?
16:55:28 <fungi> procrastinators rejoice!
16:55:32 <smcginnis> :)
16:55:35 <dhellmann> do we have a schedule for train settled?
16:55:36 <diablo_rojo> Not that I can think of?
16:55:38 <evrardjp> smcginnis: it's not listed in Ben session's draft though
16:55:48 <smcginnis> We will also have at least some hallway time during the PTG for release-specific topics.
16:55:53 <evrardjp> so we probably want to make sure PTLs are there by doing proper publicity of it
16:55:59 <dhellmann> I can imagine teams wanting to know by the ptg/forum
16:56:01 <smcginnis> dhellmann: I have a proposed schedule up.
16:56:11 <smcginnis> That would be good to finalize that.
16:56:14 <dhellmann> ok, I wasn't sure if the dates were firm -- yeah
16:56:36 <smcginnis> #link https://review.openstack.org/636742
16:56:51 <smcginnis> Not firm until we approve it, but no one has pointed out major issues with the dates yet.
16:57:33 <ttx> maybe we should now
16:57:35 <smcginnis> If it's good enough, maybe we should get that approved so it's published and we can get broader community feedback if there is anything that doesn't land at a  good time.
16:57:38 <ttx> It's FF after all
16:58:04 <smcginnis> #link http://logs.openstack.org/42/636742/2/check/openstack-tox-docs/26cf052/html/train/schedule.html
16:58:04 <dhellmann> works for me
16:58:12 <smcginnis> For your easy viewing pleasure.
16:58:47 <ttx> I would just approve it and send "this is it, if we missed something critical just let us know asap" email
16:59:11 <diablo_rojo> Hehe.. yeah.. I think doing elections is going to suck this round.
16:59:24 <smcginnis> I could mention in the countdown, but then also send its own ML post to increase odds of someone actually seeing it.
16:59:54 <diablo_rojo> If the goal is high visibility I think its own email would be better
16:59:55 <dhellmann> yeah, separate email thread
17:00:15 <dhellmann> and we should get the election officials to add those dates as early as we can
17:00:27 <prometheanfire> smcginnis: what's up?
17:00:46 <fungi> i'm open to brainstorming easier ways of handling the election scheduling for next round though i also can't be an official
17:00:56 <fungi> unless i decide not to run for the tc again that is
17:00:57 <smcginnis> Umm, think we had mentioned requirements freeze and that there are one or two libs that may or may not need to ask for an official FFE.
17:00:58 <diablo_rojo> dhellmann, thats going to require another tc convo I think. tonyb projected the dates and they look pretty simultanrous
17:01:06 <diablo_rojo> *simultaneous
17:01:21 <dhellmann> diablo_rojo : ok. that's one for mnaser then
17:01:28 <openstackgerrit> Duc Truong proposed openstack/releases master: Release python-senlinclient 1.11.0 (Stein)  https://review.openstack.org/641520
17:01:54 <diablo_rojo> fungi, yeah and if I ever want to run.. then it would be one less too
17:02:04 <fungi> yup!
17:02:06 <smcginnis> I think the only question on the schedule related to that was ATC deadline. That can be moved afterwards if it's determined it's not enough time.
17:02:23 <diablo_rojo> dhellmann, yeah I figured after this schedule got set we would bring it up in office hours or something
17:02:25 <ttx> we have one more topic, task assignment
17:02:37 <dhellmann> diablo_rojo , fungi : I might be talked into helping. I can't promise this early, though.
17:02:37 <smcginnis> ttx: Are you good with the propsoed train schedule?
17:02:43 <ttx> yes
17:02:50 <fungi> dhellmann: thanks, we'll keep that in mind
17:02:56 <diablo_rojo> dhellmann, noted :D
17:03:00 <smcginnis> Does someone want to approve that? Then I can get emails sent.
17:03:00 <fungi> (it is mostly automated at least)
17:03:05 <ttx> +2ed
17:03:06 <smcginnis> #topic Assign R-4 week tasks
17:03:15 <ttx> and+1ed
17:03:20 <smcginnis> Thanks
17:03:36 <smcginnis> The first task for next week I can include in the countdown email.
17:03:45 <ttx> The warn task should probably just be a weekly email thing
17:03:47 <ttx> yep
17:04:01 <smcginnis> The next task is thankfully a nicely scripted one.
17:04:08 <ttx> I'm happy to take the second one unless someone wants it
17:04:09 <smcginnis> diablo_rojo and evrardjp: Up for another one?
17:04:12 <smcginnis> Or ttx
17:04:26 <ttx> (I'll be around that week)
17:04:35 <evrardjp> I am not around next week
17:04:52 <smcginnis> Oh right, I should point out I'm at the Open Source Leadership Summit next week, so my availability will be spotty.
17:05:05 <diablo_rojo> smcginnis, such a leader ;)
17:05:11 <smcginnis> heh
17:05:27 <smcginnis> OK, I'll put ttx down as owning the branching task.
17:05:44 <smcginnis> OK, we're over. Anything else?
17:05:50 <ttx> smcginnis: I'm not an open source leader so I'm not invited :P
17:05:56 <smcginnis> Hah
17:06:11 <evrardjp> ttx: FOMO?
17:06:13 <ttx> all done thx!
17:06:20 <diablo_rojo> evrardjp, always
17:06:25 <smcginnis> OK, thanks everyone!
17:06:29 <evrardjp> thx
17:06:30 <smcginnis> #endmeeting