17:00:34 <zbyszek> #startmeeting FESCO (2022-09-27)
17:00:34 <zodbot> Meeting started Tue Sep 27 17:00:34 2022 UTC.
17:00:34 <zodbot> This meeting is logged and archived in a public location.
17:00:34 <zodbot> The chair is zbyszek. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:34 <zodbot> The meeting name has been set to 'fesco_(2022-09-27)'
17:00:34 <zbyszek> #meetingname fesco
17:00:34 <zodbot> The meeting name has been set to 'fesco'
17:00:34 <zbyszek> #chair nirik, decathorpe, zbyszek, sgallagh, mhroncok, dcantrell, music, mhayden, Conan_Kudo, Pharaoh_Atem, Son_Goku, King_InuYasha, Sir_Gallantmon, Eighth_Doctor
17:00:34 <zodbot> Current chairs: Conan_Kudo Eighth_Doctor King_InuYasha Pharaoh_Atem Sir_Gallantmon Son_Goku dcantrell decathorpe mhayden mhroncok music nirik sgallagh zbyszek
17:00:37 <zbyszek> #topic init process
17:00:41 <mhayden> .hi
17:00:42 <zodbot> mhayden: mhayden 'Major Hayden' <mhayden@redhat.com>
17:00:44 <zbyszek> .hello2
17:00:45 <zodbot> zbyszek: zbyszek 'Zbigniew Jędrzejewski-Szmek' <zbyszek@in.waw.pl>
17:00:47 <nirik> good morning everyone.
17:00:50 <dcantrell> .hello2
17:00:51 <zodbot> dcantrell: dcantrell 'David Cantrell' <dcantrell@redhat.com>
17:00:59 <Eighth_Doctor> .hello ngompa
17:01:02 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
17:01:05 <Eighth_Doctor> good evening all :)
17:01:16 <pboy> .hi
17:01:16 <zodbot> pboy: pboy 'Peter Boy' <pboy@uni-bremen.de>
17:01:21 <bcotton> .hello2
17:01:21 <zodbot> bcotton: bcotton 'Ben Cotton' <bcotton@redhat.com>
17:01:33 <gotmax[m]> .hello gotmax23
17:01:34 <zodbot> gotmax[m]: gotmax23 'Maxwell G' <gotmax@e.email>
17:02:59 <zbyszek> We're still one short, right?
17:03:20 <zbyszek> I think it's a holiday in Czechia.
17:03:40 <dcantrell> I thought tomorrow was
17:03:50 <gotmax[m]> mhayden, zbyszek, dcantrell, ngompa
17:03:55 <gotmax[m]> Yes
17:03:59 <zbyszek> Ah right, tomorrow.
17:04:31 <dcantrell> I've missed many weeks.  First it was really bad COVID and then immediately after we had a family medical emergency so I've been spending nights at the hospital.  But this week has me back to normal, hopefully.
17:04:36 <nirik> every day is a holiday!
17:05:01 <zbyszek> Oh, nirik. So we have 5.
17:05:02 * Eighth_Doctor is half-dead trying to realign to Barcelona time
17:05:23 <zbyszek> #topic #2863 Change: libsoup 3: part two
17:05:23 <zbyszek> .fesco 2863
17:05:24 <zodbot> zbyszek: Issue #2863: Change: libsoup 3: part two - fesco - Pagure.io - https://pagure.io/fesco/issue/2863
17:06:40 <zbyszek> Dunno, I like the plan proposed by Miro in https://pagure.io/fesco/issue/2863#comment-815849
17:06:52 <zbyszek> more than the Change proposal.
17:08:02 <nirik> yes
17:08:07 <dcantrell> that one is reasonable.  I am generally a fan of marking things deprecated which helps to start establishing a deadline for discontinuing use (be that porting, patching, or just dropping support in the dependent package--something I leave to pkg maintainers)
17:08:43 <nirik> well, we have a long history of keeping things around for a long time after they are deprecated
17:09:30 <nirik> after all, gtk+ and vte are still in repos...
17:09:53 <nirik> but I agree a controlled move to drop things is better if we can do it...
17:10:12 <MichaelCatanzaro> nirik: libsoup 2 will live on for a long time to come, it seems. Anyway we are OK with rejecting the change proposal. I've talked to kalev and we plan to orphan the package: whoever wants to keep it alive can do so
17:11:06 <zbyszek> MichaelCatanzaro: can you resubmit with a deprecation and orphaning instead of retirement?
17:11:25 <MichaelCatanzaro> zbyszek: No point: orphaning the package does not require a change proposal ;)
17:11:36 <zbyszek> Sure, but it'd be nice to raise awareness.
17:11:56 <mhayden> late to the party, but mhroncok's suggestion relative to python3's deprecation cycle looks quite good
17:12:01 <zbyszek> After all, people *are* supposed to move off it, and it'd get the ball rolling.
17:12:04 <MichaelCatanzaro> I understand FESCo has to approve the deprecation, but you can do that here, right?
17:12:50 <zbyszek> I think we'd be happy to approve it right now.
17:13:40 <zbyszek> Do we have some proposal to vote on?
17:13:57 <mhayden> proposal around deprecation, then removal later (i think?)
17:14:25 <zbyszek> Well, I think we don't want to deal with the removal at this point. It might a some time in the future.
17:14:34 <mhayden> you're correct
17:15:42 <zbyszek> Proposal: the change in current form is rejected. We encourage the Change Owner to resubmit with deprecation and a plan to orphan instead.
17:16:28 <nirik> +1
17:17:02 <mhayden> +1 (thanks zbyszek for the wording)
17:17:22 <zbyszek> dcantrell, Neal, yea or nay?
17:17:23 <dcantrell> +1
17:18:04 <zbyszek> Eighth_Doctor^
17:18:11 <MichaelCatanzaro> I really don't want to write another change proposal here... it is not required to orphan a package.
17:18:44 <gotmax[m]> Well, it's deprecate and orphan
17:18:51 <zbyszek> MichaelCatanzaro: can you just edit the exiting one?
17:19:04 <MichaelCatanzaro> Yes of course, but it requires time and effort
17:19:25 <MichaelCatanzaro> I have to write yet another change proposal to change the systemd shutdown timeout anyway...
17:19:49 <zbyszek> Anyway, that's why I wrote "encourage". I think it'd be good if it happens, but nothing more.
17:20:08 <MichaelCatanzaro> Heh, fair enough
17:20:31 <zbyszek> It seems we lost our quorum.
17:20:50 <Eighth_Doctor> zbyszek: +1
17:20:54 <zbyszek> Phew.
17:21:07 <zbyszek> #agree Approved (+5,0,0)
17:21:37 <zbyszek> #topic #2865 Change: Strong crypto settings: phase 3, forewarning 2/2
17:21:37 <zbyszek> .fesco 2865
17:21:38 <zodbot> zbyszek: Issue #2865: Change: Strong crypto settings: phase 3, forewarning 2/2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2865
17:21:45 <gotmax[m]> I don't think you marked what you're approving
17:21:53 <gotmax[m]> It'll look like you approved the actual change
17:21:54 <asosedkin> I'm here
17:22:03 <zbyszek> #undo
17:22:03 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f0defd29358>
17:22:07 <MichaelCatanzaro> gotmax[m]: 🤪
17:22:27 <zbyszek> #agree The change in current form is rejected. We encourage the Change Owner to resubmit with deprecation and a plan to orphan instead  (+5,0,0)
17:22:34 <zbyszek> I hope I got that right.
17:22:37 <zbyszek> #topic #2865 Change: Strong crypto settings: phase 3, forewarning 2/2
17:22:44 <zbyszek> .fesco 2865
17:22:45 <zodbot> zbyszek: Issue #2865: Change: Strong crypto settings: phase 3, forewarning 2/2 - fesco - Pagure.io - https://pagure.io/fesco/issue/2865
17:22:54 <zbyszek> MichaelCatanzaro: thank you for coming.
17:23:00 <MichaelCatanzaro> o/
17:23:03 <mhayden> i think the "jump scare" wording here gave people a jump scare 🤭
17:23:14 <zbyszek> asosedkin: thank's for being here too.
17:23:38 <mhayden> we're already doing these crypto settings in ELN/RHEL right now, and Fedora needs to get there. however, it's difficult to find all of the nooks and crannies where SHA1 is still in use. (but someone else might know better methods)
17:23:54 <mhayden> i caught a few when i did backports to EPEL
17:24:04 <zbyszek> In a way this topic is similar to the previous one… We need a softer mechanism than a flag day where thing suddenly break.
17:24:16 <zbyszek> *things
17:24:31 * nirik doesn't like the jump scare, but don;t let me stop it if everyone else wants to do it.
17:24:39 <asosedkin> my softening mechanism was to file 3 change pages and hold 1 test day (so far)
17:25:11 <asosedkin> but it's hard to gradually flip a switch until we implement gradual update rollouts or something =(
17:25:14 <dcantrell> I don't like the jump scare, but I also don't think that's actually going to help catch things
17:25:29 * zbyszek thinks we should have user-visible warnigs and delay disablement until a majority of those warnings go away.
17:25:46 <asosedkin> there's no such things as user-visible warnings from openssl
17:25:47 <mhayden> how do we get people to make a move with their packages before we flip a switch, though
17:25:48 <dcantrell> yeah, that's a way better approach
17:26:23 <zbyszek> asosedkin: can't you do fprintf(stderr, …) ?
17:26:27 <asosedkin> things that are left are scenarios like "I'm pairing my iPhone"
17:26:33 <asosedkin> no fprintf(stderr) will help these
17:26:52 <mhayden> part of me wondered if we can have the build system remove SHA1 so that updates are caught prior to going in -- regular users would not be affected
17:26:57 <zbyszek> It ends up in the journal. Users look at the journal when things don't work.
17:27:28 <zbyszek> And even if *users* don't look, they will report the issue in bugzilla, and somebody will ask for the journal.
17:27:30 <mhayden> some packages might not be updated for a whole release, though
17:27:35 <nirik> I think the best case is to make the change as early in the cycle as we can, then try and finish it. If we end up not doing so, we can revert at the contingency time... but planning to revert seems... weird and dishonest somehow. :(
17:27:56 <asosedkin> that's what I did (I thought that if the first part wasa
17:27:59 <mhayden> nirik: i see your point
17:28:02 <asosedkin> approved, all parts were approved)
17:28:12 <asosedkin> but I was stopped and told to wait, so here am I
17:29:02 <asosedkin> nirik: if it's only a revert for those going from rawhide to released, is it really a revert?
17:29:38 <zbyszek> So… my expectation with the current proposal is the following: people will notice that an update breaks various important-to-them use cases. They will immediately set LEGACY and forget about the whole thing.
17:29:41 <asosedkin> neither those tracking rawhide nor those upgrading between releases see it as a revert
17:30:13 <mhayden> zbyszek: hah, this reminds me of SELinux 🤭
17:30:35 <asosedkin> zbyszek: yes, for many this is gonna happen whatever we plan
17:30:49 <Eighth_Doctor> well, I wound up having to do DEFAULT:SHA1 for RHEL 9
17:30:52 <nirik> asosedkin: tons of people follow rawhide to branching, then follow the branch to release... they would be seeing a revert no?
17:31:02 <gotmax[m]> FWIW, I think zbyszek's per program opt-out mechanism idea makes sense if it's feasible
17:31:04 <asosedkin> best we can do is nudge them towards FEDORA38 and not LEGACY
17:31:10 <Eighth_Doctor> I can't fix third-party vendor RPMs and repos being unusable because of SHA-1 being removed
17:31:28 <Eighth_Doctor> which is really the biggest and nastiest consequence
17:31:43 <dcantrell> and that's the part we have no control over, but we'll hear the most about
17:31:53 <zbyszek> Eighth_Doctor: also DNSSEC
17:31:58 <Eighth_Doctor> meh
17:32:01 <mhayden> just so we're on the same page, is anyone here of the opinion that we *should not* deprecate SHA-1?
17:32:07 <Eighth_Doctor> DNSSEC is just not broadly adopted
17:32:11 <asosedkin> mhayden: define time boundary
17:32:29 <mhayden> asosedkin: you got me there! 🙃
17:32:35 <gotmax[m]> If it's enabled in rawhide and in branched until the contingency deadline, it will still get caught for packages that run tests
17:32:54 <zbyszek> mhayden: I'm completely fine with *deprecation*. It's the removal which worries me.
17:32:55 <Eighth_Doctor> we'd basically have to flip that flag on mass rebuild
17:33:17 <gotmax[m]> But what does deprecation actually look like?
17:33:30 <Eighth_Doctor> is writing warnings to the syslog or a logfile when these functions are used possible?
17:33:36 <mhayden> zbyszek: yeah, poor choice of words on my part. i don't think deprecation exists here. this feels like an ON/OFF switch
17:33:46 <zbyszek> gotmax[m]: For me, like DeprecationWarning in Python3.10.
17:34:09 * gotmax[m] nods
17:34:12 <zbyszek> Then, maybe a month later, wait 5s on the first invocation.
17:34:25 <zbyszek> We do that in systemd during boot if we detect that root is really messed up.
17:34:29 * asosedkin groans
17:35:41 <asosedkin> OK, can we have a quick show of hands for those who want to see how quickly we'll get asked to revert printing to random file descriptors from openssl? =)
17:36:01 <zbyszek> asosedkin: s/random/stderr/
17:36:12 <mhayden> only if we can put emojis in the strings 🧨
17:36:24 <Eighth_Doctor> lol
17:36:31 <asosedkin> zbyszek: you're inside cups, which closed all descriptors already. where does FD 2 point to?
17:36:35 <Eighth_Doctor> 💣️emoji for sure
17:36:41 <zbyszek> asosedkin: also, the warning must be silenacable through an envvar or similar mechanism.
17:37:02 <nirik> "🌭using SHA1, you need more mustard! 🌭"
17:37:08 <mhayden> is there something we could potentially do in mock/koji/somewhere to detect a package that depends on SHA-1?
17:37:13 <zbyszek> asosedkin: I know cups plays with argv[0] and does strange things. But CUPS is "unique".
17:37:44 <zbyszek> mhayden: I don't think so. It's hard to detect until the thing is actually used.
17:37:51 <Eighth_Doctor> mhayden: we could add rpminspect or rpmlint checks to look for common md5/sha1 stuff
17:38:09 <asosedkin> zbyszek: ok, wait, I have an idea, stop me if it's weird
17:38:13 <Eighth_Doctor> well, I say we, but I mean "someone who knows how this works"
17:38:29 <Eighth_Doctor> because we have rpmlint checks for other bad function calls
17:38:30 <dcantrell> Eighth_Doctor: that's entirely possible
17:38:40 <asosedkin> zbyszek: we have opt-in logging and probes; maybe we can just run opt-in logging for everyone without asking?
17:38:54 <asosedkin> and point it to journal
17:39:06 <zbyszek> asosedkin: you mean like a package that gets installed by default? I think this would work.
17:39:11 <asosedkin> IDK where to put such a daemon tho
17:39:55 <zbyszek> asosedkin: wouldn't it just a by system-wide daemon that gets started as part of multi-user.target?
17:39:57 <asosedkin> and then we can obsolete and retire it at some point
17:40:17 <asosedkin> zbyszek: yeah, I meant, which package.
17:40:40 <zbyszek> Oh, I think it should be a separate package. We'd pull it in through comps.
17:40:45 <asosedkin> but then we're back to the original problem
17:40:59 <asosedkin> it logs, but until we start blocking operations, nobody cares to look
17:41:17 <gotmax[m]> And then enable it by default in presets?
17:41:25 <zbyszek> gotmax[m]: also that.
17:41:28 <asosedkin> then we break it, then maintainers get just one cycle to fix it instead of 2 like I propose now
17:41:43 <zbyszek> asosedkin: we can still give them two cycles.
17:41:55 <asosedkin> zbyszek: how?
17:42:22 <zbyszek> We can wait until F40…
17:42:51 <asosedkin> no, the clock starts ticking from when we break, not from when we log =)
17:43:00 <Eighth_Doctor> so what? we'd add this in F38?
17:43:07 <Eighth_Doctor> and do what with the info?
17:43:15 <asosedkin> so I'll still be asking for my weird revert scheme
17:44:25 <asosedkin> Eighth_Doctor: that's one grandiose question. can iPhones pair with a newer hash in the signature? how recent should that be? that's something only upstream of libmobiledevice can figure out, and it'll take time
17:44:44 <asosedkin> and so will all the other exotic things that we'll only start spotting when it actually breaks
17:46:13 <zbyszek> asosedkin: thinking about it more, I think your idea with a daemon is technically brilliant, but I think that the stderr-based stupid approach will work better.
17:46:40 <zbyszek> In particular, because it makes it easy to make the warning nastier as time goes on.
17:46:50 <asosedkin> neverpanic: ^
17:47:54 <asosedkin> I don't know, folks, I'm actually hopeful we can break it in rawhide and find out it's not that bad
17:48:12 <asosedkin> I'm running it on my main machine for months already
17:48:31 <zbyszek> OK. We've been at this topic for 30 minutes…
17:48:43 <asosedkin> but if we need more time and better plans, I'll oblige
17:49:12 <asosedkin> maybe even to the stderr thing if you really want things on fire and openssl folks agree =D
17:49:20 <Eighth_Doctor> I think if we want to go with "let's break everything approach" we probably need code checks to detect and flag obvious md5/sha1 usage
17:49:25 <nirik> yeah, so that was my hope... we could break it, fix all the blockers and drive on... but I know how life is.
17:50:04 <asosedkin> break it, fix all the blockers *over two cycles*
17:50:18 <zbyszek> asosedkin: is there any hope for a per-application or per-process overrides?
17:51:06 <asosedkin> zbyszek: not until there appears an interface for it. editing unit files and desktop files? ain't nobody got time for that, LEGACY hammer here we come =/
17:51:23 <neverpanic> Ugh, stderr. Please not :(
17:52:46 <zbyszek> OK. Let's hold the vote.
17:53:15 <zbyszek> Proposal: approve the change as-is (with a plan to revert the removal in F38 once it's branched)
17:54:26 <mhayden> +1
17:54:37 <nirik> 0 I guess. won't stand in the way
17:54:47 * zbyszek wanted to vote 0, but if everybody else is in favour, I'll vote +1 too to avoid +4,1,0 failure.
17:55:14 <gotmax[m]> If you mark your proposals with `#idea` (or `#info`), they'll show up in the minutes ;-)
17:56:16 <zbyszek> #info Proposal: approve the change as-is (with a plan to revert the removal in F38 once it's branched)
17:56:45 <zbyszek> Eighth_Doctor, dcantrell?
17:57:16 <Eighth_Doctor> 0
17:57:22 <dcantrell> 0, I don't have a better idea right now but I think this change requires more coordination and communication.  I am not really a fan of the jump scare approach, but like I said I don't have a better idea right now
17:57:24 <Eighth_Doctor> I'm very weak on this
17:57:35 <zbyszek> 0 too
17:58:12 <zbyszek> #agree Approval rejected (+1, 4, 0)
17:58:24 * mhayden stands in a lonely spot
17:58:41 <asosedkin> to the drawing board /me goes
17:59:01 <mhayden> asosedkin: rope me in and i will be happy to help you
17:59:10 <zbyszek> asosedkin, mhayden: thank you both.
17:59:37 <zbyszek> OK, let's try to go over the remaining points quickly.
17:59:38 <zbyszek> #topic #2868 Release Notes Improvement
17:59:38 <zbyszek> .fesco 2868
17:59:39 <zodbot> zbyszek: Issue #2868: Release Notes Improvement - fesco - Pagure.io - https://pagure.io/fesco/issue/2868
18:00:11 <zbyszek> I think we've mostly hammered out an agreement in the ticket.
18:00:16 <zbyszek> pboy: any comments?
18:00:21 <pboy> nope
18:00:34 <zbyszek> bcotton: what do you think? Can we add selection menu to categorize Change pages?
18:00:58 <bcotton> can, yes. should, i'm not so sure about
18:01:52 <zbyszek> bcotton: do you have a different approach in mind?
18:02:25 <bcotton> > Parsing the existing Release Notes field in the Change proposals into a file which the docs team sorts would accomplish some of the improvements without introducing additional process challenges.
18:02:53 <zbyszek> bcotton: that's the plan as I understand it.
18:03:00 <bcotton> even with the categories pre-entered in the proposal template, we still sometimes get people who mistype them and so they disappear
18:03:34 <pboy> bcotton There is apost-processing to capture these cases.
18:03:42 <pboy> a post-processing
18:03:48 <bcotton> zbyszek: it's not, because of the addition of categorization
18:04:28 <bcotton> i think the return on investment here is incredibly low
18:04:39 <bcotton> but if someone wants to give me a list to put in the template, i'll shrug and move on with life
18:04:45 <zbyszek> My understanding is that there are two steps: one is to gather the Name+Summary+Release notes for the text, and the other step is ask people to categorize their changes into a few few broad groups.
18:06:31 <zbyszek> pboy: should we try that and see how that goes?
18:07:21 <pboy> yes,I would appreciate. I would like to have complete and trustworthy release notes. And I think we have 6-8 categories to select from. Hat should be managable
18:07:42 <zbyszek> Anyone against?
18:07:52 <zbyszek> (I'm counting bcotton as +/- 0 ;))
18:08:27 <Eighth_Doctor> I have not been able to read and evaluate the ticket as-is
18:08:38 <zbyszek> OK. So:
18:08:45 <zbyszek> #action pboy to provide a list of categories
18:08:59 <zbyszek> #action fesco folks: read the proposal and vote in the ticket
18:09:27 <zbyszek> We have one more topic on the agenda: Change proposal: Replace DNF with DNF5
18:09:39 <zbyszek> Should we continue with that, or should we wrap it up for today?
18:09:46 <Eighth_Doctor> wrap it up
18:09:50 <nirik> I think it needs more baking...
18:09:54 <Eighth_Doctor> there's still discussion on devel about that change anyway
18:09:55 <Eighth_Doctor> and in the ticket
18:09:55 <dcantrell> it would be nice to keep these meetings to <= 1 hr
18:10:01 <gotmax[m]> I mainly came to discuss this, but unless nobody has anywhere else to be, punting might be a good idea :)
18:10:17 <Eighth_Doctor> well, I want to go get food and then crash for the evening
18:10:21 <zbyszek> Yeah, punting would be my preference too. I need to eat something urgently.
18:10:33 <zbyszek> #topic #2870 Change proposal: Replace DNF with DNF5
18:10:34 <zbyszek> .fesco 2870
18:10:35 <zodbot> zbyszek: Issue #2870: Change proposal: Replace DNF with DNF5 - fesco - Pagure.io - https://pagure.io/fesco/issue/2870
18:10:40 <zbyszek> #info postponed to next week
18:10:40 <Eighth_Doctor> it's 8pm here now :)
18:10:46 <Eighth_Doctor> and I haven't eaten much of anything since leaving New York yesterday
18:10:54 <zbyszek> Eighth_Doctor: that's how it works in Europe.
18:11:05 <zbyszek> 8PM, dark and cold.
18:11:14 <zbyszek> #topic Next week's chair
18:11:17 <Eighth_Doctor> yeah...
18:11:34 <zbyszek> So… I'm travelling next week, so I can't commit to chairing.
18:11:41 <Eighth_Doctor> I'll probably not be around next week since Akademy 2022 is ongoing
18:11:44 <zbyszek> A "volunteer" is needed.
18:12:25 <zbyszek> dcantrell, nirik, mhayden?
18:12:44 <dcantrell> I cannot commit to anything right now due to our ongoing family medical situation.  I have no idea what Tuesday will be like for me
18:13:11 <mhayden> i can do next week!
18:13:12 <nirik> next week is start of final freeze... I guess I could do it, but sounds like no quorum?
18:13:25 <zbyszek> #action mhayden will chair next meeting
18:13:30 <mhayden> 🪑
18:13:34 <zbyszek> nirik: hmm, maybe.
18:13:41 <mhayden> nirik: you doubt we will get many people?
18:13:41 <zbyszek> #topic Open Floor
18:13:41 <nirik> well, we can try I guess
18:14:22 <zbyszek> #info https://pagure.io/fesco/issue/2874 is open. Please vote.
18:14:48 <zbyszek> (Though I see that only dcantrell hasn't, from the FESCo members here…)
18:15:02 <zbyszek> I'll close in a minute unless somebody has something.
18:15:15 <dcantrell> zbyszek: I voted
18:15:25 <zbyszek> No wait… Yeah. I was about to say that I'm blind.
18:15:36 <dcantrell> ok, just making sure I'm looking at the same thing
18:15:43 <zbyszek> Eighth_Doctor didn't vote.
18:16:02 <zbyszek> #endmeeting