18:00:07 <nirik> #startmeeting FESCO (2012-02-27)
18:00:07 <zodbot> Meeting started Wed Feb 27 18:00:07 2013 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:07 <nirik> #meetingname fesco
18:00:07 <nirik> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:00:07 <nirik> #topic init process
18:00:07 <zodbot> The meeting name has been set to 'fesco'
18:00:07 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:00:13 <nirik> who all is around?
18:00:15 <mitr> Hello
18:00:38 <pwouters> (me)
18:01:24 <jamielinux> (me)
18:01:25 <mattdm> (me)
18:01:30 * sgallagh is here
18:01:38 * abadger1999 here
18:01:40 <sgallagh> Apologies if I drop out, I'm on a train
18:01:55 <jwb> i'm here
18:01:58 <pjones> hello.
18:02:36 <nirik> ok, I guess lets go ahead and dive in...
18:02:43 <nirik> #topic #979 Features process proposal: Track features in bugzilla
18:02:43 <nirik> .fesco 979
18:02:43 <nirik> https://fedorahosted.org/fesco/ticket/979
18:02:45 <zodbot> nirik: #979 (Features process proposal: Track features in bugzilla) – FESCo - https://fedorahosted.org/fesco/ticket/979
18:03:17 <nirik> I guess my thought here is to do whatever the program manager would prefer, try it and if it fails, try something else? :)
18:03:42 <mattdm> as the person proposing this idea, yeah, I can get behind that :)
18:03:43 <sgallagh> I can get behind that
18:04:00 <abadger1999> +1
18:04:08 <t8m> hi all, sorru for being late
18:04:10 <mitr> I generally agree with that
18:04:18 <jwb> i'm going to get to the side of it
18:04:22 <sgallagh> Is jreznik in favor of this?
18:04:22 <nirik> I can see advantages and disadvantages to trac or bugzilla.
18:04:37 <nirik> He's prefering trac at the moment.
18:04:45 <mattdm> yep. As I said in the bug, I prefer bugzilla, but I prefer trac to nothing
18:04:51 <sgallagh> worksforme
18:05:10 <sgallagh> mattdm: I think I prefer Trac, honestly. Fedora has more control to tweak it if we need to
18:05:13 <t8m> I actually prefer trac
18:05:38 <mitr> Do we keep this open, or close it and let jreznik come up with a specific proposal, or something else?
18:05:47 <jreznik> sorry for being late
18:05:48 <mattdm> To me, the big advantage of bugzilla is the ability to link *directly* to actual-work bugs
18:05:55 <mitr> (I might be overthinking the "proposal" part)
18:05:57 <nirik> trac has problems, but so does bugzilla. I think we should look at trying something and fail faster. ;)
18:05:58 <pjones> I've never thought trac does a good job - it does a lot of simple things badly, like making urls in titles not clickable
18:06:14 <mattdm> which means that once set up, it's low overhead to keep up-to-date rather than being Yet Another Thing to update
18:06:42 <jreznik> does anybody know anything about that devconf proposal marcela was talking about?
18:06:50 <mitr> jreznik: next week
18:06:52 <sgallagh> mitr: Can we just close it with "agreed with a minor addendum"?
18:07:26 <mitr> sgallagh: any of the three options works for me
18:07:30 <sgallagh> s/Can/Should/
18:07:35 <jreznik> nirik: well both are not a good tracking tools, trac is more, bz is less but...
18:07:35 <nirik> so, proposal: go with whatever option the program manager would like to try?
18:07:44 <nirik> jreznik: agreed. :(
18:07:59 <t8m> nirik, +1
18:08:05 <jreznik> and I see mattdm's point
18:08:14 <mitr> nirik: +1.  Just please make sure this gets announced/incorporated into the planning process
18:08:39 <sgallagh> nirik: +1
18:08:46 <nirik> sure, and perhaps we should dicuss more details on the options, but that doesn't need to be here...
18:09:02 <jreznik> nirik: yep, definitely
18:09:30 * jreznik is not open/closed for any good idea how to track it - wiki is even worst than bz/trac
18:09:58 <jreznik> is open is better and not against any viable option :)
18:10:08 <nirik> so, thats +4 for the proposal? other votes?
18:10:20 <jwb> which proposal?
18:10:25 <nirik> so, proposal: go with whatever option the program manager would like to try?
18:10:33 <jwb> yeah, +1
18:11:12 <jreznik> of course in coop with fesco
18:11:24 <nirik> #agreed FESCo is ok to go with whichever tracker the program manager would like
18:11:46 <pjones> yeah, +1
18:12:03 <nirik> thanks jreznik. I suppose we could discuss the options on list, but there might be a lot of bikeshedding.
18:12:41 <nirik> anyhow, moving on...
18:12:54 <nirik> #topic #1028: tor package concerns
18:12:54 <nirik> .fesco 1028
18:12:54 <nirik> https://fedorahosted.org/fesco/ticket/1028
18:12:55 * mattdm gets out his bikeshed paint
18:12:57 <zodbot> nirik: #1028 (tor package concerns) – FESCo - https://fedorahosted.org/fesco/ticket/1028
18:13:06 <nirik> mattdm: but what colour is it? ;)
18:13:19 <nirik> anyhow, I reopened this because I still have a concern...
18:13:42 <nirik> The maintainer doesn't want to push security impacting updates to stable without karma.
18:13:52 <pwouters> (i can voice an opinion too if that's appropriate)
18:14:02 <nirik> pwouters: sure.
18:14:06 <pjones> pwouters: go ahead.
18:14:18 <pwouters> this has been going on for about 3 years now. in different ways
18:14:21 <nirik> jamielinux: Your input would be welcome too.
18:14:28 <jamielinux> nirik: Great.
18:14:45 <pwouters> i am very close with upstream, and they totally gave up and now strongly recommend not using fedora/epel packages
18:15:06 <nirik> pwouters: is that from them being out of date? or some other issue?
18:15:10 <pwouters> this has gone on against everyone's but a single person's (enrico) interest
18:15:29 <pwouters> out of date, patches that degrade security from upstream's point of view,
18:15:40 <pwouters> weirdness like different init susb systems
18:15:54 <pwouters> there's like 50+ emails in the archive about tor packaging (and actually clamav packaging)
18:16:14 <jamielinux> (e.g. https://lists.fedoraproject.org/pipermail/devel/2013-February/178407.html )
18:16:28 <pwouters> fesco kind of forced the co-maintainer
18:16:44 <pwouters> who then did work, then the maintainer just revered without talking to the comaintainer
18:16:46 <nirik> For the record, jamielinux is who was added as a tor comaintainer.
18:16:55 <pwouters> so i am dont think the current solution is working
18:17:06 <sgallagh> I'm not sure I'd want to make a general ruling on security updates here, but in the case of the Tor package (whose only reason for existence is to enhance anonymity) I think it might be reasonable to recommend that it push to stable with the timeout
18:17:26 <jwb> frankly, i don't think focusing on tor is going to solve the problem
18:17:34 <jwb> the problem is the maintainer, not the package.
18:17:40 <pjones> yeah :/
18:17:58 <jamielinux> I was quite disheartened after my changes were all reverted.
18:17:59 <mitr> For updates, I'd be surprised if we were able to come up with a general rule, it'll always involve human judgment.  We can just emphasise Fedora's preference to stay with upstream
18:18:04 <pwouters> yes. the comaintainer was supposed to mostly fix the maintainer issue. not the issue of whatever is happening today or tomorrow
18:18:14 <sgallagh> True, should we perhaps send a sternly-worded email about collaborating with comaintainers?
18:18:14 <nirik> FYI, when f16 went eol:
18:18:18 <nirik> 141  https://admin.fedoraproject.org/updates/FEDORA-2012-14654/tor-0.2.2.39-1600.fc16
18:18:21 <nirik> 141 days
18:18:37 <mitr> jamielinux: I have reviewed the commit, and I would have probably reverted it as well.  The split version is much better.
18:18:39 <sgallagh> And then revoke his rights if he doesn't shape up?
18:18:57 <mitr> sgallagh: ^^
18:19:09 <jamielinux> Just for the record, I have just posted a split patch series here:
18:19:11 <jamielinux> https://lists.fedoraproject.org/pipermail/devel/2013-February/179163.html
18:19:21 <jamielinux> I have no doubt that Enrico will revert almost all of them however.
18:19:24 <sgallagh> mitr: Wait, so it wasn't just a revert? I misunderstood the problem, then
18:19:36 <jamielinux> I have not applied any of these in git yet, as I see no point.
18:19:43 <pwouters> mitr: while i agree attacking whitespace could have waited, the whole "non fedora init" style should be ripped out
18:19:50 <mitr> sgallagh: Look at http://pkgs.fedoraproject.org/cgit/tor.git/commit/?id=dcca5c196a47528c40b4563dac9bf0adf892cc89 , it shows how large the thing was
18:19:52 <sgallagh> jamielinux: I don't think it's our job to pre-approve your patches.
18:19:56 <mitr> pwouters: yes
18:19:59 <pwouters> it should have been ripped at when it was initng
18:20:07 <jamielinux> sgallagh: No, I wasn't suggesting that. Just posting here for the record.
18:20:11 * sgallagh nods
18:20:19 <nirik> mitr: yeah, although really... it's not that big. I would have been able to view the diff...
18:20:36 <mitr> IMHO all the %{?fedora} conditionalizing should be generally forbidden - just use git branches and merge.
18:20:53 <pwouters> the core issue is, the tor package is for the fedora community, not for enrico. Enrico is mixing this up. He should follow package guidelines. He's refused to comply for over 3 years.
18:20:57 <mitr> OTOH we have asked FPC recently about support for other init systems, and they decided that they don't want to forbid them
18:21:35 <pjones> mitr: yeah, but %{?fedora} is something we've never really taken a strong stance on
18:21:45 <mitr> pjones: And I understand we probably won't.
18:21:47 * nirik notes upstart is now dead/blocked in rawhide
18:21:54 <nirik> and f18
18:21:55 <mitr> Too many people find it more convenient than branches.
18:21:59 <jamielinux> The tor spec contains a tor-upstart package that isn't built, which I assume is fine by our guidelines as I couldn't find any guidance.
18:22:11 <pjones> jamielinux: yeah, I think that's an okay thing to do.
18:22:19 <mitr> https://fedorahosted.org/fpc/ticket/243 for the record
18:22:26 <jamielinux> pjones: Sure, that's what I assumed.
18:22:56 <pwouters> also: tor security updates are vital. and should not be delayed willy nilly
18:23:14 <nirik> anyhow, in the past when we have had issues like this we have selected a mediator... do we want to do that here? Or ask ensc some questions directly? or ?
18:24:33 <pwouters> mediation is good. provided there is an action if it fails
18:24:47 <pwouters> I'm reminded of last time fesco got involved with tor packaging. nothing ended up changing
18:25:02 <pjones> yeah, that's the thing we want to avoid happening again.
18:25:04 * nirik doesn't recall that... I know we have talked about clamav several times.
18:25:26 * mitr finds https://fedorahosted.org/fesco/ticket/347
18:25:28 <pjones> Might be worth having a mediator and expecting that mediator to come to us with resolution or at least strong recommendations within a couple of weeks.
18:25:36 <pwouters> nirik: I met up with upstream at GSoC a few years ago, and filed like 8 bugs needing fixing.
18:25:37 <daumas> https://fedorahosted.org/fesco/ticket/347
18:26:50 <pwouters> i think that ticket is from _after_ I gave up on it all
18:27:06 <mitr> Well, mediator... I kind of think we know what we want to achieve here already, it's just that we don't have (and don't want to set up) guidelines backing it
18:27:07 <nirik> ah yeah. Now I remember that one.
18:27:29 <abadger1999> mitr: what do we want to achieve here?
18:27:38 <pjones> mitr: you're suggesting that somebody else should be maintaining these packages?
18:28:13 <mitr> abadger1999: 1) updates to this specific package going out soon enough to make upstream content, 2) not insisting on packaging peculiarities
18:28:16 <pwouters> https://bugzilla.redhat.com/show_bug.cgi?id=532373
18:28:23 * nirik would like timely updated packages that upstream is happy to recommend to users.
18:28:39 <t8m> nirik, +1
18:28:43 <t8m> me as well
18:28:55 <mitr> pjones: I don't think that's strictly necessary, no.  But talk about "mediators" and "cooperation" when we want to say "rip this out" is confusing the issue
18:29:27 * abadger1999 agrees with mitr's sentiment of being clear
18:29:28 <t8m> mitr, in 2) you mean who should not insist? fedora or enrico?
18:29:54 <pwouters> (not in that bz that Roger Dingledine is upstream)
18:29:59 <pwouters> s/not/note
18:30:00 <mitr> Perhaps we might consider overruling FPC on https://fedorahosted.org/fpc/ticket/243 (and/or forbidding upstrart and allowing sysvidinit, since upstrart never existed that much),...
18:30:15 <abadger1999> mitr: Uhmm...
18:30:16 * nirik oddly sees tor was not in the mass rebuild?
18:30:24 <abadger1999> mitr: I'd prefer you didn't go at it in that manner :-)
18:30:30 <mitr> abadger1999: yeah
18:31:08 <mitr> abadger1999: I see the difficulty - it's just that seeing "you can have packaging that nobody else needs" and "we don't like how tor is packaged" is not consistent.
18:31:26 * abadger1999 notes that ensc's method of enabling upstart is definitely.... idiosyncratic.
18:31:31 <mitr> t8m: "allowing the package to remove bits that only make it more complex for comaintainers"
18:31:59 <t8m> mitr, I am still not getting it
18:32:21 <abadger1999> he's not using parallel installable init scripts for different systems... he's using bcond_with/without to make the build conditionalized via command line arguments
18:32:36 <abadger1999> so you'll never get the non-default behaviour in the fedora build system.
18:32:56 <abadger1999> only if you build the package locally with your own set of command line arguments to rpmbuild
18:33:00 <jamielinux> Yes, the tor-upstart package is not built by default.
18:33:12 <jamielinux> Though the spec is horribly lengthy and confusing with all of the custom stuff.
18:33:28 <jamielinux> After my most recent patch series, the length drops from 250 to 150.
18:33:35 <jamielinux> And is *much* easier to grok.
18:33:40 * nirik nods.
18:33:50 <jamielinux> But spec legibility is subjective.
18:33:50 <pwouters> yeah because three years ago there was hell and fire because you needed to install "tor-sysvinit" to get tor. and that fight caused enrico to fix it so "yum install tor" would get the default init system
18:34:00 <pjones> jamielinux: sure, but less is usually more.
18:34:06 <pwouters> but that also took weeks of fighting :/
18:34:20 <pwouters> again. the specific package detail is not the problem. The maintainer is.
18:34:22 <abadger1999> I think the fpc made a ruling about something similar (macros for use on non-fedora OS's [like suse openbuildsystem]) and said that those macros should not be used.... but that ruling was in the first few years of fedora.
18:34:26 <jwb> again, the problem is basically that you have a primary maintainer treating a package as a fifedom and pissing all over anything anyone else tries
18:34:30 <pjones> But all of this is just a side-show.
18:34:36 <jwb> so focus on the maintainer, not the damn pacakge
18:34:54 <pjones> The problem FESCo needs to address isn't each individual package change that needs to go through - it's the fact that the maintainer is actively stopping things from getting better.
18:34:55 <abadger1999> jamielinux: I think legibility is a huge thing.
18:35:14 <jamielinux> abadger1999: I agree with you 100%.
18:35:30 <nirik> right, so one thing I think we might want to look at documenting/whatever is the fact that packages you maintain are not yours. You are simply a caretaker. You shouldn't treat them as your own thing and reject things that make them easier to hand on to others.
18:35:31 <sgallagh> pjones: And that's supposed to be FESCo's job (I kid)
18:35:32 <abadger1999> jamielinux: the fact that ensc can jsutify reverting the patch solely on the "impossible to review" grounds points at problems in the current spec's readability.
18:35:35 <t8m> either we have the "balls" to kick enrico out of being primary tor maintainer or we should probably accept his "style" in spec unless it is not conflicting the guidelines
18:36:10 <mitr> pjones: I'm not too keen on using that revert as a basis for our decision.
18:36:28 <jwb> mitr, then use the combined history of the maintainer's actions
18:36:30 <pjones> mitr: that's not the only example that's been cited though.
18:36:41 <pjones> and do note that this is a /recurring/ problem.
18:36:44 <pwouters> mitr: how about upstream recommendation that fedora packages for to should not be used?
18:36:47 <jwb> why on earth do we suddenly have tunnel vision when we have to possibly talk to a human about their behavior?
18:36:48 <pwouters> is that a better indication?
18:36:49 <mitr> abadger1999: No, the patch mixes about 8 separate changes; that's problematic regardless of what you are patching
18:37:19 <mitr> pjones: Right, I was reading your comment too narrowly.  Sorry
18:37:25 <abadger1999> mitr: It's certainly no worse than a new package review, though.
18:38:02 * nirik notes we are at 24min on this topic.
18:38:04 <jwb> proposal: remove Enrico from tor maintainership
18:38:39 * jamielinux would like to mention he did feel at fault for the massive commit and whitespace changes that weren't fully required, and was kicking himself after. But did feel Enrico didn't handle the situation well either.
18:39:00 <abadger1999> jwb: +1
18:39:08 * nirik is a reluctant +1.
18:39:12 * abadger1999 notes that he's also willing to vote for "lesser" proposals.
18:39:19 * pjones is also a +1 , though wishes it hadn't come this far.
18:39:41 <mitr> 0.  I think I'm still looking for a less radical fix, although I can see the case for a +1
18:40:18 <nirik> we could ask him to apply the split out patches, and push security updates stable...
18:40:27 <nirik> but not sure that would fully solve things.
18:40:29 <pjones> mitr: if you have any suggestions for a less radical fix, now is the time.
18:40:48 <pjones> nirik: if we're going to tell him how to maintain the package, what's the point of leaving him in place as maintainer?
18:40:50 <mitr> the best I can think of as a counter-proposal is "FESCo wants tor updates to go out timely enough from now on, and is willing to remove maintainership over this issue"
18:40:57 <mitr> Which is really not great
18:41:10 <sgallagh> I'm still not quite well enough informed to decide. Can someone give me the 30-second explanation of why tor has to see Fedora-specific patches on a regular basis vs. rebasing? Does it go against our stable updates policy in some way?
18:41:10 <nirik> pjones: yeah.
18:41:13 <jamielinux> pjones: I absolutely agree with your second comment.
18:41:27 <jamielinux> pjones: And there is a long history too..
18:41:52 <nirik> sgallagh: it's not fedora specific. Tor updates, ensc updates the package, it sits in updates-testing. It doesn't get +3 karma, it never goes stable.
18:41:59 <mitr> pjones: Well, "telling others how to maintain the package" is the whole point of packaging guidelines... and what we want never was in them
18:42:15 <pjones> mitr: no, there's a difference between setting guidelines and saying "make these changes".
18:42:16 <nirik> the package itself has lots of issues preventing it from easily being managed by co-maintainers.
18:42:17 <pwouters> i've been involved with a few rounds with this issue. I like being nice and doing another round, but I dont think it will work. enrico showed not the least bit of cooperation willingness in years
18:43:02 <jamielinux> nirik: Yes, making this patch series was a lot more work than I anticipated, with bits of the spec all over the palce.
18:43:29 <jamielinux> nirik: Not that I mind putting in the work to fix the package..
18:43:40 * sgallagh really doesn't want to be the swing vote on this, but I suppose staying at 0 would be an implicit -1.
18:43:54 <sgallagh> We have a comaintainer who is willing to do the work needed, so I guess I'm a weak +1
18:44:03 <mitr> sgallagh: Give me a minute...
18:44:39 <sgallagh> If enrico later demonstrates he can play well with others, he can always request to be re-added as a comaintainer
18:44:42 * nirik waits for a counterproposal from mitr
18:44:52 <pwouters> actually, I will also go back to Roger at upstream and see about bringing theirs and our packages back togehter, so they can stop shipping rpms and tell people to not use fedora packages
18:45:16 <t8m> I'd be willing to give +1 if there was a clear response (or clear ignorance) from enrico that he is not willing to change his maintenance style of tor even if we remove it from him forcibly if he doesn't
18:45:31 <mitr> After looking at bugzilla a bit more, I'm +1 to the proposal
18:45:47 <mitr> t8m: What swayed me was the CVE bugs in CLOSED/WONTFIX - EOL
18:46:00 <pjones> mitr: yeah, that's incredibly bad.
18:46:13 <nirik> ok, lets see... thats +7?
18:46:45 <jwb> someone points out the CWG arguably exists for things liek this
18:46:51 <jwb> i've yet to see CWG actual exist though
18:46:55 <jwb> so...
18:47:24 <nirik> so, thats +6, and t8m's conditional +1, which I guess is 0 or -1 for the proposal?
18:47:31 <abadger1999> jwb: yeah -- -ENOTIMe on my part and I think this may have progressed beyond CWG already.
18:47:45 <t8m> nirik, rather 0
18:47:49 <nirik> t8m: ok.
18:47:51 <jwb> for the record: i do not take pleasure in proposing this, but i think it needs to be done
18:48:04 <jwb> if i had any thoughts something else would work, i would have proposed that instead
18:48:13 <nirik> #agreed remove Enrico from tor maintainership (+6,0,0)
18:48:25 <nirik> I assume we can orphan it and jamielinux will pick it up?
18:48:44 <jwb> yes
18:48:47 <nirik> jwb: I'm in the same boat. Its a sad state. :(
18:48:51 <nirik> anyhow, moving on then...
18:49:00 * jamielinux would like to thank everyone here for the discussion, input and advice.
18:49:02 <nirik> #topic 1091 NRM: Request ownership change for mediawiki
18:49:02 <nirik> .fesco 1091
18:49:02 <nirik> https://fedorahosted.org/fesco/ticket/1091
18:49:03 <zodbot> nirik: #1091 (NRM: Request ownership change for mediawiki) – FESCo - https://fedorahosted.org/fesco/ticket/1091
18:49:13 <daumas> (I'm mooninite FYI)
18:49:24 <nirik> welcome daumas
18:49:43 <nirik> since the maintainer hasn't responded, I'm fine moving ownership here.
18:49:46 <mitr> I think this is a pretty clear-cut case for the NRM process, just that we didn't handle this on the mailing list.
18:49:55 * mitr apologizes for not reacting there
18:50:09 <nirik> We may want to consider if other of the maintainers packages should also be orphaned or co-maintainers added.
18:50:56 <pjones> I think we should probably solicit co-maintainers for them.
18:51:03 <sgallagh> pjones: +1
18:51:07 <nirik> do we even need a vote on mediawiki? should be pretty clear under the policy.
18:51:12 <pwouters> (not having mediawiki1XX packages strongly recommended)
18:51:27 <nirik> we still likely need them for epel, but yeah.
18:51:35 <mitr> nirik: It needs an explicit ACK from >=1 FESCo member
18:51:45 <sgallagh> mitr: I'll ack it
18:52:07 <mitr> sgallagh: you were faster :)
18:52:09 <daumas> pwouters: could those packages be blocked for fedora only? they were never reviewed for fedora. only epel
18:52:09 <nirik> would someone like to manage soliciting co-maintainers for the other packages of theirs?
18:52:19 <pjones> proposal: make daumas (mooninite) the maintainer and solicit for co-maintainers for the owner's other packages.
18:52:22 <nirik> daumas: most if not all of them should be already
18:52:51 <pjones> (whether we need a vote or not, we're already discussing it and having a record can't hurt)
18:53:17 <sgallagh> daumas: That came up on the mailing list some time ago. They accidentally filtered in from rawhide (which wasn't dead.package like it should have been)
18:53:18 <nirik> sure, +1
18:53:25 <sgallagh> I'm in favor of killing it and blocking the packages
18:53:34 <daumas> nirik, sgallagh: ok thanks
18:53:51 <sgallagh> pjones: +1
18:53:59 <nirik> https://admin.fedoraproject.org/pkgdb/users/packages/athimm?acls=owner are the 27 packages by the way
18:54:00 <mitr> pjones: +1.
18:54:16 <t8m> pjones, +1
18:54:44 <nirik> #agreed make daumas (mooninite) the maintainer and solicit for co-maintainers for the owner's other packages. (+5,0,0)
18:54:51 <nirik> anything else on this topic?
18:54:59 <daumas> thanks for your time, gentlemen
18:55:06 <nirik> #topic next week chair
18:55:15 <nirik> who wants the shiny gavel?
18:55:54 <sgallagh> nirik: I think it's my turn
18:55:54 <nirik> anyone?
18:56:00 <nirik> cool. thanks sgallagh
18:56:06 <nirik> #info sgallagh to chair next week
18:56:10 <nirik> #topic Open floor
18:56:14 <nirik> any items for open floor?
18:56:24 <sgallagh> Can we vote on blocking those mediawikiXXXX packages from Fedora?
18:56:44 <nirik> I don't think there would be any objection.
18:57:00 <pjones> sgallagh: dude, whatever.
18:57:02 <sgallagh> I don't either, but it's good to have a record of decisions
18:57:28 <nirik> all of them are blocked except 119
18:57:31 <nirik> and that was a mistake. ;)
18:57:33 <sgallagh> If no one is objecting, I'll just shut up and go do it
18:57:43 <abadger1999> .whoowns mediawiki119
18:57:43 <zodbot> abadger1999: smooge
18:57:58 <abadger1999> sgallagh: yeah, mistake, just do it.
18:58:13 <sgallagh> #action sgallagh to fix mediawiki119 mistake
18:59:18 <abadger1999> Just a note that any help on this cleanup would be appreciated: https://fedoraproject.org/wiki/User:Toshio/Devendorize_desktop_files#List_of_affected_packages
18:59:36 <abadger1999> halfway done, but half still to go.
19:00:16 <nirik> abadger1999: I noticed we still have that python-pillow ticket open.
19:00:21 <nirik> does that need to be anymore?
19:00:32 <abadger1999> Hmm..
19:00:39 <abadger1999> So there is one question around that ticket I think
19:00:41 <nirik> https://fedorahosted.org/fesco/ticket/985
19:00:56 <abadger1999> dmalcolm hasn't responded on the bug against python3
19:00:59 <nirik> ok
19:01:36 <nirik> anything else from anyone? will close out in a minute if not.
19:01:39 <abadger1999> Do we want to ask him what's going on with that in some official capacity?
19:01:55 <nirik> a ping on the bug might be nice.
19:02:08 <abadger1999> k.  I'll put on a fesco hat and ask.
19:02:36 <nirik> #action abadger1999 to ping on python3 pillow bug
19:03:36 <nirik> ok, thanks for coming everyone.
19:03:39 <nirik> #endmeeting