15:00:05 <jforbes> #startmeeting FESCO (2019-05-06)
15:00:05 <zodbot> Meeting started Fri May  3 15:00:05 2019 UTC.
15:00:05 <zodbot> This meeting is logged and archived in a public location.
15:00:05 <zodbot> The chair is jforbes. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:05 <zodbot> The meeting name has been set to 'fesco_(2019-05-06)'
15:00:05 <jforbes> #meetingname fesco
15:00:05 <zodbot> The meeting name has been set to 'fesco'
15:00:05 <jforbes> #chair nirik, bowlofeggs, jforbes, zbyszek, bookwar, sgallagh, contyk, mhroncok, otaylor
15:00:05 <zodbot> Current chairs: bookwar bowlofeggs contyk jforbes mhroncok nirik otaylor sgallagh zbyszek
15:00:05 <jforbes> #topic init process
15:00:13 <contyk> .hello psabata
15:00:13 <zodbot> contyk: psabata 'Petr Šabata' <psabata@redhat.com>
15:00:29 <bcotton> .hello2
15:00:33 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
15:00:49 <sergiodj> .hello2
15:00:51 <zodbot> sergiodj: sergiodj 'Sergio Durigan Junior' <sergiodj@redhat.com>
15:01:17 <ignatenkobrain> .hello2
15:01:18 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <i.gnatenko.brain@gmail.com>
15:01:20 <zbyszek> .hello2
15:01:23 <bowlofeggs> .hello2
15:01:23 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
15:01:26 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
15:02:16 <sgallagh> .hello2
15:02:17 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:02:22 <nirik> morning
15:02:26 <jforbes> Yay quorum
15:02:42 <bowlofeggs> jforbes: might be good to add a topic to the end for the election, since f30 is released
15:02:50 <mhroncok> hey, sorry for being late
15:03:26 <jforbes> what sort of topic?
15:03:43 <bowlofeggs> jforbes: maybe it's not a topic, but a reminder ha
15:04:00 <jforbes> #topic #2088 F31 Change – “dnf --best” as default behavior
15:04:00 <jforbes> .fesco 2088
15:04:00 <jforbes> https://pagure.io/fesco/issue/2088
15:04:02 <zodbot> jforbes: Issue #2088: F31 Change – “dnf --best” as default behavior - fesco - Pagure.io - https://pagure.io/fesco/issue/2088
15:05:33 <jforbes> So we said we wanted a response from jmracek and we got one
15:07:25 <jforbes> There is still the issue of whatever due diligence we do to ensure that our repositories are not broken, we have no control over any 3rd party repos that users have enabled
15:08:36 <zbyszek> FWIW, I'm still -1. jmracek's answers did not change this.
15:08:36 <bowlofeggs> is pagure down? i can't post on it :/
15:09:10 <mhroncok> seems so
15:09:31 <bowlofeggs> sent an e-mail instead
15:09:55 <nirik> it's fine here?
15:10:10 <mhroncok> back up
15:10:12 <zbyszek> bowlofeggs: e-mail to what address?
15:10:36 <jforbes> zbyszek: /dev/null
15:11:15 <bowlofeggs> zbyszek: i replied to pagure via e-mail, hoping that a faithful SMTP server would eventually get it to the ticket ☺
15:11:28 <bowlofeggs> seems that it did not make it
15:12:05 <bookwar> honestly, i am +1 for a change, and I am ok with gnome software having different behavior. For me cli tooling is needed when I am looking for more precise and clear info than when I am using GUI, so my expectation is that gnome software tries to make it nice, but dnf should be honest about any error happening in the background
15:12:23 <jforbes> Does this mean we need to let this stew more in ticket?
15:12:48 <zbyszek> jforbes: I don't think stewing more is going to yield a tastier ... ticket.
15:12:59 <zbyszek> Let's just get on with it and make a vote.
15:13:04 <jforbes> bookwar: I agree that cli doesn't need to match gnome
15:13:07 <bookwar> and i would be worried if we put "the impression we make on users" over the "clear and honest reply in case of errors" at least in cli
15:13:26 <mhroncok> i think there are two parts of the problem: 1) "broken upgrade paths in the Fedora repositories" - and we should really do our best to detect this before we ship it tot users
15:13:46 <mhroncok> 2) given that (1) is solved, what should be the default for 3rd party repos
15:13:55 * nirik doesn't think we should depend on users to file bugs about dep problems in our repos. ;(
15:14:37 <jforbes> mhroncok: we have zero control over 3rd party repos.  We generally do a good job with 1.
15:14:47 <bowlofeggs> otaylor seems to feel strongly about differences between cli and gui, but i personally think it's ok for them to have different behaviors - i'd be interested to hear his perspective more, as i think he's thougth about it more than i have
15:14:57 <mhroncok> jforbes: we do a good job?
15:15:15 <zbyszek> jforbes: no, not at all. Check how many broken upgrade paths we still have for F29 to F30.
15:15:32 <zbyszek> There's even one in common bugs for ant/maven/something that we can't seem to solve.
15:15:35 <jforbes> zbyszek: upgrade paths are different than update paths
15:15:39 <bowlofeggs> my personal worry here is that a user could miss a critical security update because ffmpeg can't install
15:15:45 <mhroncok> we have plenty of uninstallable packages with broken depencnecies in the repos, some broken since Fedora 26
15:15:54 <bowlofeggs> like, a security update in something from us
15:16:08 <bowlofeggs> (i used ffmpeg since that's 3rd party, not because it fails to install - it works great ☺)
15:16:22 <nirik> mhroncok: yep... but we should fix that
15:16:33 <mhroncok> we totally should
15:17:02 <mhroncok> i think we cannot approve this before we fix it
15:17:10 <mhroncok> and even then, the 3rd party problem remains
15:17:19 <nirik> best is global right?
15:17:33 <bowlofeggs> it sounds global, but i'm not sure
15:18:02 <mhroncok> it happens quite often for me that virtualbox kmod whatnot or chromium freeword libs get out of sync and are skipped in update
15:18:21 <mhroncok> and i still get all other updates
15:18:44 <mhroncok> this would just fail and stop, right?
15:19:09 <nirik> yep
15:19:15 <nirik> until you passed --no-best
15:20:09 <mhroncok> that makes me say: -1 until we can mitigate our own problems server side, -0.5 after that
15:20:15 <bowlofeggs> the proposal doesn't really clearly state what the user experience will be when there's a problem
15:20:28 <nirik> I wonder if this could be a per repo setting... so we set ours to just best=false and 3rd party get default... and we switch to best=true once we have our repos better fixed?
15:20:53 <zbyszek> bowlofeggs: I think it does. The expecations is that bugs will be filed, and the user will use --no-best after careful review of the problem.
15:21:03 <jforbes> not sure what the behavior would be there nirik
15:21:04 <bowlofeggs> i get that they can say --no-best, but how will the user know to do this? will the user *understand* what is happening?
15:21:07 <mhroncok> that's not realistic
15:21:25 <bowlofeggs> will they know if they are missing an important security update if they *don't* use --no-best?
15:22:34 <jforbes> bowlofeggs: There isn't anything that lists CVEs in the default output, and even if there were, that wouldn't exactly convey the urgency
15:23:31 <bowlofeggs> yeah, and today the user would get the security updates that can be installed, so it's less of a problem
15:23:34 <bookwar> for me it is not about triggering users to file bugs, but about providing proper feedback and reporting the error when it happens, not trying to make an impression that there wasn't anything about it
15:23:55 <bookwar> we don't require people to file bugs but we are open about what is going on
15:23:56 <bowlofeggs> but this proposal will stop them from getting security updates when *any* repo has a problem, and it will not tell them they are missing those updates
15:24:01 <bowlofeggs> i think i dislike that about this
15:24:27 <bowlofeggs> if it gave a warning that they were missing security updates *and* told them they might be able to get them with --no-best that might assuage my fears
15:25:15 <jforbes> And what about automated runs of dnf update -y
15:25:30 <jforbes> where people don't ever look at the output
15:25:31 <nirik> that should use dnf-automatic. ;)
15:25:36 <bowlofeggs> yeah automated runs just won't get it, unless someone is reading their cron e-mails
15:25:55 <bowlofeggs> but does dnf-automatic use --no-best?
15:26:00 <bowlofeggs> and/or, can it?
15:26:06 <nirik> not currently, but it coud
15:26:08 <jforbes> nirik: some of us are lazy, if it ain't broke...
15:26:22 <nirik> you can override any dnf setting in automatic... so you could set best=whatever
15:26:27 <bookwar> bowlofeggs: do we have security updates configured by default?
15:26:34 <nirik> (if you knew to)
15:27:18 <bowlofeggs> nirik: but yeah, you'd have to know to as well
15:27:36 <bowlofeggs> bookwar: default in what?
15:27:40 <jforbes> bookwar: we don't limit to security, but I am guessing most users simply run 'dnf update' to get everything
15:28:23 <bookwar> i mean automated security updates are not enabled by default in workstation, user needs to enable them explicitly?
15:28:51 <nirik> yes, we don't enable any auto updating at all for rpms
15:29:02 <nirik> (but we do for flatpaks)
15:29:38 <bowlofeggs> bookwar: oh you mean for gnome software?
15:29:57 <bowlofeggs> i dont' think this proposal should affect gnome software, though i could be wrong
15:30:22 <bowlofeggs> bookwar: but yeah, i don't think we do any automated updates
15:30:32 <mhroncok> (I would like to vote or move on)
15:30:34 <bowlofeggs> (by default)
15:30:41 <bookwar> then i think we don't change that much: those who run `dnf update` manually will react on errors, those who configure security updates, need to configure them anyway, those who get updates from gnome software will use behavior from gnome software
15:31:10 <bowlofeggs> bookwar: well it does change because today users will get security updates when possible
15:31:17 <bowlofeggs> and that's my concern
15:31:35 <bowlofeggs> now they get a hard to understand error, and won't be told the importance of using --no-best
15:31:48 <bowlofeggs> it seems like a disservice to me
15:32:08 <jforbes> bookwar: people who do a 'dnf update' now will get security updates, they just may not know that they are security updates.  And I would guess a lot of people see a failed command output and figure try again tomorrow.
15:32:52 <jforbes> perhaps they run --skip-broken if it is recommended in the output
15:33:59 <bowlofeggs> i think i would not mind this if there were very clear messages to the user, including informing them of whether there are secuity updates that might apply if --no-best is used
15:34:15 <bowlofeggs> but the proposal doesn't really talk about the user experience very explicitly
15:34:28 <nirik> shall we vote? or punt down the road?
15:34:36 <mhroncok> the peoposal is very clear: change the default
15:34:40 <jforbes> Either way, the change request isn't changing, so we need to vote or bring it back to the ticket
15:34:46 <bowlofeggs> of course, the security updates could still fail even with --no-best, but that's a problem we can't fix here ☺
15:34:50 <mhroncok> I don't think thay planned to update the error messages, etc. at all
15:35:09 <bowlofeggs> mhroncok: i think without better error messaging, i'm a -1
15:35:16 <bookwar> bowlofeggs: i understand that security update is important, but it is just one aspect. Imaging person who runs `dnf update`, doesn't get errors, goes away, only to realize that the update wasn't actually installed. I was that person, and i actually filed an issue about that in bugzilla couple of years ago, because it is confusing and misleading
15:35:43 <bowlofeggs> bookwar: yeah i agree that is also a bad thing
15:35:58 <bowlofeggs> i think this is making it worse though, unless it has better error messaging
15:36:24 <nirik> it could in theory even do both...
15:36:26 <bowlofeggs> i'd rather have today's problem than the problems i perceive with this proposal, if that makes sense
15:36:58 <mhroncok> bowlofeggs: would you be able to write specific requirements to the ticket?
15:37:06 <nirik> dnf update ... "foo-1.2-1.fc30 has broken deps" <pause for 10 seconds> "continuing with --no-best to apply everything else"
15:37:24 <bowlofeggs> ok, my vote is -1, but i can also express to the OP that i could be flipped to a +1 by amending the proposal to have a "what the user sees when there's a problem" section that addresses my concerns
15:37:36 <bowlofeggs> mhroncok: yeah
15:37:40 <mhroncok> nirik: or even interactivity
15:37:53 <mhroncok> bowlofeggs: so let's do that and punt in the meantime?
15:38:07 <bowlofeggs> but, if the other fesco members get +5, we can also just approve this and move on ☺
15:38:08 <nirik> I'm also -1 to the current proposal, but would ask the change owner to discuss with the community the best behavior here and revisit and resubmit.
15:38:26 <jforbes> bowlofeggs: they won't get +5
15:38:44 <zbyszek> nirik: I like this above just rejecting...
15:38:45 <bowlofeggs> cool. in that case i'll write up my thougths on the ticket and what it would take to get me to be +1
15:38:55 <sgallagh> I'm -1 for the moment as well. I think `--best` is a better long-term solution, but I agree the messaging and current state of broken repos is problematic.
15:38:57 <bowlofeggs> #action bowlofeggs will document how to get him to vote +1
15:39:05 <jforbes> proposal: bowlofeggs will update the ticket with concerns that need to be addressed before we vote
15:39:05 <sgallagh> The latter is less of a problem for RHEL
15:39:16 <bowlofeggs> jforbes: +1
15:39:27 <sgallagh> jforbes: +1
15:40:07 <contyk> +1
15:40:31 <nirik> sure, +1 (I don't know that we need to vote on it)
15:40:43 <mhroncok> ack
15:40:45 <jforbes> #agreed bowlofeggs will update the ticket with concerns that need to be addressed before we vote
15:40:59 <zbyszek> ack
15:41:37 <jforbes> #topic #2125 F31 System-Wide Change: Set skip_if_unavailable default to false
15:41:38 <jforbes> .fesco 2125
15:41:38 <jforbes> https://pagure.io/fesco/issue/2125
15:41:39 <zodbot> jforbes: Issue #2125: F31 System-Wide Change: Set skip_if_unavailable default to false - fesco - Pagure.io - https://pagure.io/fesco/issue/2125
15:42:51 <mhroncok> here it seems the dicussion that was supposed to happen on devel moved to the ticket
15:43:24 <zbyszek> I'm happy to treat this as an internal detail under discretion of the DNF maintainers. Fedora already sets it for its own repos (with one exception), so the default doesn't change much. I don't think we need to micro-manage this.
15:43:46 <jforbes> zbyszek: I tend to agree
15:44:13 <jforbes> Though making it a change request also helps ensure the changed default gets communicated
15:44:29 <zbyszek> I'd also argue that skip_if_unavailable=false is a better default.
15:44:50 <zbyszek> jforbes: yep, and that's a totally reasonable use of the Change process
15:44:52 <mhroncok> and again, UX is not part of the proposal
15:46:02 <mhroncok> I have concerns, but I tent to agree with zbyszek
15:46:13 <mhroncok> *tend
15:46:23 * nirik is fine just saying +1 here, let them handle UI (with input from interested parties for sure)
15:46:37 <mhroncok> +1
15:46:53 <jforbes> +1
15:46:57 <sgallagh> +1
15:46:59 <zbyszek> UI could/should be improved. Right now it just says Error: Failed to synchronize cache for repo '...'.
15:47:02 <zbyszek> +1
15:47:02 <nirik> although kalev makes a good point
15:47:21 <contyk> also +1
15:48:39 <bowlofeggs> yeah i think kalev's argument is sound
15:48:45 <jforbes> nirik: some of the 3rd party repos explicitly set it anyway (negativo for instance)
15:48:50 <nirik> also as a side note, copr also sets this true
15:49:12 <mhroncok> as long as this is documented behavior, with proper actionable error messages, it doesn't matter
15:49:40 * nirik nods
15:50:29 <jforbes> bookwar bowlofeggs?
15:50:34 <bowlofeggs> i'm on the fence
15:50:41 <bowlofeggs> it seems pretty similar to the last ticket to me
15:51:08 <bowlofeggs> again, a third party repo can cause a user not to get updates because of a default (obvs, they can cause it now by just having the setting in the repo file…)
15:51:25 <jforbes> bowlofeggs: no matter what the default is, they have that power
15:51:26 <bowlofeggs> and again, security updates could be missed
15:51:39 <bowlofeggs> jforbes: yeah, but the default makes it more likely to happen
15:51:44 <bowlofeggs> the proposed default i mean
15:51:53 <jforbes> One can also argue that there are just as many security issues in 3rd party packages
15:52:08 <bookwar> jforbes: i am +1
15:52:10 <bowlofeggs> well i wouldn't say "as many" just because we have way more packages than they do
15:52:25 <bowlofeggs> i'm happy to be out voted, but i'm -1 unless there is also good messaging here too
15:52:34 <jforbes> bowlofeggs: we have a massive number of packages that are less exposed, and are not installed
15:52:57 <jforbes> and the messaging is pretty clear, the update errors out with which repository can't be reached
15:53:06 <mhroncok> proposal: ...
15:53:25 <bowlofeggs> looks like we have +5 anyway, so let's just accept and move on ☺
15:53:26 <mhroncok> change is approved, but the error message must be actionable by the user
15:53:47 <bowlofeggs> we don't have to be unanimous
15:53:54 <jforbes> mhroncok: again, the error  message is pretty clear.
15:54:07 <mhroncok> failed to synchronize ?
15:54:18 <jforbes> yes
15:54:37 <mhroncok> does it say how to disable the repo or make it skip if unavailable permanently?
15:54:45 <zbyszek> mhroncok: no
15:54:52 <bowlofeggs> like the last one, it doesn't tell the user that they are missing important security updates that might be retrievable with the flag though
15:54:54 <mhroncok> then it's not actionable
15:56:17 <zbyszek> mhroncok: proposal: change is approved on the condition that the error message must specify a hint how to skip the unavailable repo
15:57:08 <mhroncok> and how to to restore the previous default for it
15:57:09 <bowlofeggs> the "User experience" section of the change should show proposed dnf output of what the UX would be like
15:57:17 <mhroncok> yes
15:57:23 <jforbes> zbyszek: while not a bad idea, I don't think the change should be contingent on it
15:57:44 <bookwar> mhroncok: i don't think we should put the whole "how to disable a repo" doc in error message
15:57:56 <bowlofeggs> (we do have a majority +1, so we can just approve and move on)
15:58:09 <nirik> I think we are getting to low level here... I don't think we want to do UX design for dnf here?
15:58:19 <zbyszek> bookwar: the hint would essentially be 'Use --disablerepo=foo as a work-around.'
15:58:21 <nirik> I mean, it could use some work, but...
15:58:21 <jforbes> nirik: exactly
15:58:23 <bowlofeggs> nirik: well UX does matter when security updates are on the line
15:58:25 <bookwar> but adding smth like "failing due to skip_if_unavailable=false" would be nice
15:58:44 <bowlofeggs> UX is part of any human interactive program spec
15:58:49 <bowlofeggs> and this is a spec
15:59:04 <bowlofeggs> so i think it is good to specify the UX
16:00:02 <nirik> sure, but are we all on the dnf team? should we go over their PR's next?
16:00:07 <jforbes> bowlofeggs: but it isn't tied to this change. There have been security issues in rpmfusion packages, which could have just as easily been failed because fedora-repos weren't available
16:00:12 <nirik> I guess they did submit the change, but still...
16:00:40 <bowlofeggs> jforbes: i believe this change will make users more likely to miss security updates in fedora's repos, which is why i am concerned
16:00:45 <bowlofeggs> it seems just like the last ticket to me
16:00:56 <mhroncok> ok, let's count the votes for the change as is, and we can submit our unsolicited UX advice perosnally
16:00:59 <bowlofeggs> i.e., i think it will raise the frequency of users missing security updates
16:01:09 <bowlofeggs> mhroncok: +1
16:01:11 <jforbes> bowlofeggs: I disagree
16:01:13 <zbyszek> mhroncok: ack
16:01:19 <bowlofeggs> jforbes: ok
16:01:33 <bowlofeggs> i'm -1 to the change as is, but we have a majority +1 so that's fine ☺
16:01:41 <nirik> FYI, another datapoint: rpmfusion repos don't seem to set this, so they would get the default currently
16:01:42 <jforbes> #agreed F31 System-Wide Change: Set skip_if_unavailable default to false is approved (+7,0,-1)
16:02:30 <jforbes> nirik: though they likely might change that if the default no longer meets their desired behavior
16:02:44 <nirik> sure, they could...
16:03:27 <jforbes> #topic #2126 F31 Change: Minimal GDB in buildroot
16:03:27 <jforbes> .fesco 2126
16:03:27 <jforbes> https://pagure.io/fesco/issue/2126
16:03:28 <zodbot> jforbes: Issue #2126: F31 Change: Minimal GDB in buildroot - fesco - Pagure.io - https://pagure.io/fesco/issue/2126
16:03:44 * bowlofeggs is +1 in ticket
16:03:52 * mhroncok is +1 in ticket
16:03:56 <zbyszek> +1 here
16:03:57 <jforbes> I am +1
16:04:07 <bowlofeggs> do we want this to wait the usual week for ticket voting though?
16:04:17 * sergiodj is here in case you have any questions
16:04:20 <jforbes> I did, but sgallagh asked it be included
16:04:24 <bowlofeggs> ah
16:04:41 <bowlofeggs> sgallagh: did you have something you wanted to discuss on this one, or did you just want to fast track it?
16:04:47 <jforbes> (ticket wasn't even filed yet when I did the agenda)
16:04:52 <ignatenkobrain> I don't think there is much point in delaying things
16:04:54 * nirik is +1
16:05:54 <bookwar> +1 as well
16:06:47 <jforbes> #agreed F31 Change: Minimal GDB in buildroot is approved (+6,0,0)
16:07:13 <sgallagh> bowlofeggs: The maintainers asked if it could be discussed. The ticket was just late.
16:07:22 <bowlofeggs> ah cool
16:07:24 <sgallagh> +1
16:07:26 <mhroncok> would +6 demand a week has passed?
16:07:27 <bowlofeggs> no worries
16:07:37 <sgallagh> mhroncok: My +1 makes it +7
16:07:39 <bowlofeggs> mhroncok: normally yes, but if we do it in a meeting it's fine
16:07:41 <mhroncok> +7 makes it ok
16:07:54 <jforbes> #topic Next week's chair
16:08:00 <mhroncok> me
16:08:11 <jforbes> #action mhroncok will chair the next meeting
16:08:14 <sgallagh> I may not make it next week. Summit recovery
16:08:20 <jforbes> #topic Open Floor
16:08:27 <ignatenkobrain> I would appreciate if we can get +7 on https://pagure.io/fesco/issue/2122
16:08:30 <bowlofeggs> #info FESCo elections are coming soon!
16:08:32 <jforbes> sgallagh: have fun at summit
16:08:58 <mhroncok> ignatenkobrain: approved tomorrow anyway
16:09:28 <ignatenkobrain> ah
16:10:11 <jforbes> unless your bringing attention to it here gets someone on the fence to -1 it :)
16:10:31 * zbyszek votes _1
16:10:36 <zbyszek> just joking ;)
16:10:53 <jforbes> Anything else for open floor?
16:11:36 <zbyszek> Reviews of F30 are generally favorable.
16:11:40 <zbyszek> It's always nice to see this.
16:11:48 <jforbes> Indeed it is
16:12:24 <Southern_Gentlem> some are running into issues in #fedora over the hidden grub
16:12:48 <jforbes> Southern_Gentlem: actual issues, or just confusion?
16:13:04 <Southern_Gentlem> both
16:13:09 <sergiodj> yesterday I had issues with grub as well
16:13:24 <mhroncok> bowlofeggs: is there anything special fesco should do before or during the elections?
16:13:27 <sergiodj> anyway, don't want to extend the meeting
16:14:16 <bowlofeggs> mhroncok: i don't think so, other than nominate and fill out interviews if your seat is up for grabs
16:14:21 <jforbes> mhroncok: I think they generally file a ticket for feedback on interview questions
16:14:35 <bowlofeggs> i actually don't plan to run again this round, because i'm having a baby in like 2 months and will be MIA as a result for a long time
16:14:47 <jforbes> bowlofeggs: congrats!
16:14:52 <bowlofeggs> but i think i will run again next round!
16:14:55 <bowlofeggs> thanks!
16:14:58 <zbyszek> bowlofeggs: congrats!
16:15:12 <jforbes> Okay, if nothing else for the meeting...
16:15:16 <bcotton> bowlofeggs: yeah, like the next 18 years ;-) congratulations, though
16:15:20 <bowlofeggs> hahaha
16:15:20 <sgallagh> bowlofeggs: Congratulations :)
16:15:35 <mhroncok> bowlofeggs: congrats, will miss you
16:15:39 <jforbes> #endmeeting