=================================== #fedora-meeting: FESCO (2012-02-27) =================================== Meeting started by nirik at 18:00:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-02-27/fesco.2013-02-... . Meeting summary --------------- * init process (nirik, 18:00:07) * #979 Features process proposal: Track features in bugzilla (nirik, 18:02:43) * LINK: https://fedorahosted.org/fesco/ticket/979 (nirik, 18:02:43) * AGREED: FESCo is ok to go with whichever tracker the program manager would like (nirik, 18:11:24) * #1028: tor package concerns (nirik, 18:12:54) * LINK: https://fedorahosted.org/fesco/ticket/1028 (nirik, 18:12:54) * LINK: https://lists.fedoraproject.org/pipermail/devel/2013-February/179163.html (jamielinux, 18:19:11) * LINK: https://fedorahosted.org/fpc/ticket/243 for the record (mitr, 18:22:19) * LINK: https://fedorahosted.org/fesco/ticket/347 (daumas, 18:25:37) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=532373 (pwouters, 18:28:16) * AGREED: remove Enrico from tor maintainership (+6,0,0) (nirik, 18:48:13) * 1091 NRM: Request ownership change for mediawiki (nirik, 18:49:02) * LINK: https://fedorahosted.org/fesco/ticket/1091 (nirik, 18:49:02) * LINK: https://admin.fedoraproject.org/pkgdb/users/packages/athimm?acls=owner are the 27 packages by the way (nirik, 18:53:59) * AGREED: make daumas (mooninite) the maintainer and solicit for co-maintainers for the owner's other packages. (+5,0,0) (nirik, 18:54:44) * next week chair (nirik, 18:55:06) * sgallagh to chair next week (nirik, 18:56:06) * Open floor (nirik, 18:56:10) * ACTION: sgallagh to fix mediawiki119 mistake (sgallagh, 18:58:13) * LINK: https://fedorahosted.org/fesco/ticket/985 (nirik, 19:00:41) * ACTION: abadger1999 to ping on python3 pillow bug (nirik, 19:02:36) Meeting ended at 19:03:39 UTC. Action Items ------------ * sgallagh to fix mediawiki119 mistake * abadger1999 to ping on python3 pillow bug Action Items, by person ----------------------- * abadger1999 * abadger1999 to ping on python3 pillow bug * sgallagh * sgallagh to fix mediawiki119 mistake * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * nirik (92) * mitr (40) * pwouters (31) * sgallagh (30) * abadger1999 (26) * pjones (24) * jamielinux (23) * jwb (17) * t8m (11) * zodbot (8) * jreznik (8) * mattdm (6) * daumas (5) * mmaslano (0) * notting (0) -- 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-16... 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=dcca5c196a47528c40b... , 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... 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