18:00:01 #startmeeting FESCO (2011-11-14) 18:00:01 Meeting started Mon Nov 14 18:00:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:01 #meetingname fesco 18:00:01 The meeting name has been set to 'fesco' 18:00:01 #chair notting nirik ajax cwickert mjg59 mmaslano t8m pjones sgallagh 18:00:01 #topic init process 18:00:01 Current chairs: ajax cwickert mjg59 mmaslano nirik notting pjones sgallagh t8m 18:00:19 Hello 18:00:30 morning all. 18:01:01 I'm here but splitting my attention 18:01:16 hi 18:01:32 * cwickert is here but needs to leave later 18:01:43 * ajax waves 18:01:50 * jsmith lurks 18:01:52 Hi 18:01:53 notting will be unable to attend today, but has voted in many tickets. 18:02:02 * abadger1999 lurks 18:02:09 we have a pretty full docket, so, lets go ahead and dive in. 18:02:21 #topic #667 Request to fix CRITPATH update process 18:02:22 .fesco 667 18:02:23 nirik: #667 (Request to fix CRITPATH update process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/667 18:02:33 so, I don't think we got much QA feedback on this last week... 18:02:45 proposal: defer another week for more feedback 18:02:55 aye 18:03:00 fine by me 18:03:06 Sure 18:03:16 nirik, given the amount of topics for today, I am OK with defering 18:03:25 ok. 18:03:41 #info will defer this for a week looking for more input from QA/Tester folks. 18:03:53 #agreed will defer this for a week looking for more input from QA/Tester folks. 18:04:00 #topic #692 Adjust FESCo election policy 18:04:01 .fesco 692 18:04:03 nirik: #692 (Adjust FESCo election policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/692 18:04:15 we talked about this last week, but didn't come to any conclusion. 18:04:42 I've brought it up on list. Sorry for taking so long to do so. 18:04:47 I am here. 18:04:53 * nirik is happy to have qa folks able to be in fesco, but there's not any easy way to do it off hand... 18:04:56 We may want to wait to see if there's more feedback 18:05:16 I agree, there is no hurry now. 18:05:33 notting suggested "some combination of packager, qa, proventester, rel-eng" 18:05:33 yeah, there's no deadline on this so we can wait for more feedback with no issue. 18:05:50 * nirik notes again the 'qa' group is not used. 18:05:52 qa and releng are already packager 18:06:04 (the current members that is) 18:06:11 except I think one 18:06:14 proventester is very easy to attain. ;) Just ask, agree that you read the docs and you are in. ;) 18:06:17 I guess the same for proven tester 18:06:37 (although I suppose it shows you can follow process and read docs. ;) 18:06:38 yeah, the proventester would seem to me like an easy backdoor 18:06:39 and proventester is going away if I recall? 18:06:51 abadger1999: yeah, thats the last topic which we deferred. ;) 18:06:55 (as part of changing the critpath requirements) 18:06:59 Honestly if we're broadening it, we might as well just remove all the restrictions 18:07:00 abadger1999: we've not ruled on that one way or the other yet. 18:07:16 ah -- thought it was tentatively approved pending feedback from qa 18:07:24 proposal: defer this another week for feedback and ideas? 18:07:44 mjg59: last week there were some reasons brought up not to do that, mostly involving ambassadors 18:08:03 (and they seemed a little distasteful but not wrong to me) 18:08:30 I think the argument was that non tech people would run and be unable to make technical decisions... 18:08:32 pjones: I've no problem with ambassadors standing. If they're competent then I've also got no problem with them being elected. 18:08:37 I have no idea how true that would be however. 18:08:57 If we think there's a real risk that inappropriate people would be elected then I think we already have larger problems 18:09:08 * mmaslano would ask QA what do they think 18:09:40 * nirik nods. I'd personally be fine with cla_done + 1... 18:10:27 * abadger1999 thinks there is a risk of inappropriate people being elected but doesn't think it hurts in the long run to try new things. 18:10:32 I'd probably prefer to stay with the current rules although I am not strictly against cla_done+1 18:11:52 so, proposal to defer? or would someone care to make a counter? 18:12:09 If you open up fesco election you risk turning them into popularity voting contest some one from the design team decides to run and the whole design community votes for him not such a good idea... 18:12:30 i'm reasonably sure fesco elections are already popularity contests. 18:12:46 vi TODO 18:12:49 hah! 18:13:04 * abadger1999 pretty sure they are too... thus, the argument in favor of restricting the candidate pool :-/ 18:13:08 well, as an entirely anecdotal data point, i don't vote that way. 18:13:17 pretty much all elections regardless of context are popularity contests 18:13:53 * nirik notes also that packager isn't that big a hurdle... just see the last elections. You can find someone to sponsor you if you are at all known to the community. 18:14:07 nirik, +1 18:14:31 for that reason I'd prefer to stay with the current rules 18:14:38 nirik: but who would vote for that person? 18:14:40 so ... 18:14:46 nirik: yeah, that's looking more and more like a reasonably good point. Should we just go ahead and endorse that as a plan? 18:14:52 drago01: well, I guess we will see? ;) 18:15:00 nirik: ;) 18:15:23 proposal: leave it as is, ie, requiring packager to run for FESCo ? 18:15:30 nirik, +1 18:16:02 sigh, no reasonable counter proposal, so yes +1 18:16:14 I'd prefer to wait for more community feedback 18:16:36 I'm not necessarily against that since it seems to have worked, but I don't see any reason not to wait for more feedback. 18:16:58 * bpepple gives a +1 from the bleachers. 18:17:00 * nirik is ok waiting. 18:17:08 I'm in favor of sticking with "packager" 18:17:26 so, thats 3 for waiting, 3 for packager? 18:18:15 i'm for waiting 18:18:25 not that there's much difference really. 18:18:30 so, really without passing anything we fall back to waiting? 18:18:33 since a vote to wait is a vote to keep it as it is for now. 18:18:33 yeah. 18:19:22 ok, so I guess we defer by lack of any other thing passing. ;) 18:19:36 #action defer to next week, collect feedback and revisit. 18:19:50 #topic #690 F17 Feature: move all to /usr https://fedoraproject.org/wiki/Features/UsrMove 18:19:51 .fesco 690 18:19:54 nirik: #690 (F17 Feature: move all to /usr - https://fedoraproject.org/wiki/Features/UsrMove) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/690 18:20:31 the more i read this the more it sounds entirely sensible. 18:20:43 +1 18:20:45 -1 18:20:55 * pjones is +1 as well 18:20:57 -1 18:20:57 notting was a +1 in ticket with: "I'm tentatively OK with this, although I have concerns about the implementation on upgrade - I don't want to have a /bin directory with a forest of symlinks inside it, for example." 18:21:10 I did not change my opinion that it is a solution looking for a problem 18:21:11 nirik: actually -- that would be a -1 wouldn't it? 18:21:11 Although I lean somewhat towards being concerned about the /bin+/sbin merging 18:21:21 nirik: Since there is no implementation that doesn't do that? 18:21:31 abadger1999: good point 18:21:44 I am definitely against the /bin /sbin merging 18:21:47 mjg59: FPC has said no to that portion as well. 18:21:56 bin/sbin isn't a huge win imo 18:22:29 mjg59: I'd suggest that fesco take that portion out of the feature to avoid the further discussions that leaving it in would entail. 18:22:34 * abadger1999 nods at ajax 18:23:02 i also have some reservation about relying on the initramfs so much, we've already got at least one bug against f16 where it sticks around for your entire boot cycle just so you can tear down raid cleanly at shutdown 18:23:06 I'm still concerned with the amount of work here vs gain. It's changing 900 of our packages in order to... have more things in /usr so it's easier to have remote mounted /usr ? 18:23:18 I see 3 +1s and an argument about what notting means 18:23:31 nirik: that's also my concern + implementation 18:23:57 haraldh: are you around to answer questions? 18:24:25 sure 18:24:30 nirik: remote /usr is already a thing people claim to want though. 18:24:38 * nirik notes cwickert was +1 in the ticket earlier as well. 18:24:48 without sbin/bin it's a lot less packages to touch 18:25:15 without moving them at all? or without merging them? 18:25:26 without merging them 18:25:37 how so? you still need to touch them to move them? 18:25:38 cwickert, Are you still +1 on this? 18:25:52 t8m: yes 18:25:56 nirik, sure, but not /usr/sbin 18:26:12 haraldh: ok, right. 18:26:20 the thing with bin+sbin was that if we have simlinks all pointing to /usr/bin every location works the same. and it does not matter anymor who puts which tool where. we have both by default in $PATH anyway 18:27:08 kay: we do have both in path, but search order still matters for some things. 18:27:30 ajax, which nobody should rely on 18:27:31 abadger1999: can you pass on the FPC reasoning on that decision? or is it long? 18:27:32 anyway.. 18:27:33 ajax: which tools? 18:27:43 kay: anything that uses consolehelper, at a minimum. 18:27:53 ajax: that is going away 18:28:06 kay, how so? 18:28:26 kay, have you already prepared patches for all the packages that use consolehelper? 18:28:50 ajax: relying on initramfs is only when you decide to split off /usr, nothing changes when / and usr is on the same partition 18:28:50 kay: yeah, so's X. 18:29:13 ajax: ? 18:29:15 t8m, "move consolehelper real binaries from /usr/sbin/* to /usr/lib// or /usr/libexec/ and change consolehelper to look in these places. " 18:29:27 that is on the feature page 18:29:31 not good enough? 18:29:51 haraldh, it is still sometimes useful for root to call the binaries directly without the consolehelper influence 18:30:03 kay: "it's going away" isn't an argument that holds a lot of water with me, given how many releases it took to drop hal, and how many it's still taking to drop consolekit. 18:30:09 t8m, nobody prevents the superuser to do that with the full path 18:30:14 haraldh, and as for root sbin is before bin in $PATH that is the current status 18:30:17 kay: if it's not _gone away_ it's not gone and not something you get to just brush aside. 18:30:20 haraldh, bleach 18:30:43 nirik: details are in the FHS basically. Merging /bin and /usr/bin (and the other directories mentioned) would not violate the letter or spirit of the FHS (with the initramfs distinction) 18:31:30 * nirik sees -2, +4 and one +1perhaps from notting. 18:31:31 nirik: contrariwise, /sbin and /bin are separated in the FHS due to organization and so merging them is a violation of the FHS. 18:31:43 ajax: but hal is gone, and ck will go too. it just takes a while sometimes, when no immediate pressure requires to get rid of something. but i don't think we had any serious problems with that approach. did we? 18:32:15 nirik: I don't see how it could be approved, when FPC disagree at least with some points 18:32:22 abadger1999: fhs forbids libexec too :) 18:32:33 kay: i think "serious problems" depends on the scope of who you're talking to, and beyond that i think we're getting off-topic. 18:32:37 mmaslano: those parts need to be dropped or they need to convince FPC I guess. 18:32:42 We can certainly approve it subject to certain aspects being negotiated with FPC 18:32:51 kay: Yes. But we've specifically excepted that due to conflicting advice from the GNU Coding standardds. 18:33:04 kay: bin and sbin are separated in the GNU coding standards as well. 18:33:17 kay: So merging them would violate both standards. 18:33:35 it does not "violate" the standards 18:33:36 anyway, like i say, i think this is a wholly reasonable thing to try to do. i forsee issues but that's not new. 18:33:41 proposal: have feature owners adjust feature to meet FPC / FHS and revisit. 18:33:43 abadger1999: no we would only have the tools available in both directories at the same time :) 18:33:59 I don't think anywhere is mentioned: "All sysadmin tools have to be in /sbin" 18:34:13 (additionally, ask notting to clarify his /bin symlinks proviso) 18:34:16 it's only : "if there is /sbin, sysadmin tools should be in there" 18:34:25 nirik: I guess we have no other possibility 18:34:29 I don't see any benefit in asking them to talk to FPC first 18:34:35 Either FPC agree and then we have the conversation again 18:34:40 Or FPC disagree and it makes no difference 18:34:44 Let's just vote on *our* position 18:34:49 yeah 18:34:56 With nothing we say to be taken as overruling FPC 18:35:03 haraldh: you can claim that it doesn't violate the FHS but in Fedora, the FPC decides that. 18:35:19 And I have no interest at all in having an argument about what the FPC thinks or doesn't think right now 18:35:22 This isn't the venue 18:35:24 * nirik thinks we have empowered the FPC to handle guidelines, and shouldn't overrule them. 18:35:26 abadger1999, just my humble opinion :) 18:35:29 abadger1999: Ehhh... let's not have that discussion, shall we? 18:35:41 nirik, I agree 18:36:00 Anyway 18:36:08 haraldh: Do you have any response to notting's concern? 18:36:09 anyhow, I'm -1 18:36:11 haraldh: I constantly recommend just getting rid of that part so that this can go through the Feature process more quickly instead of going to FPC to be deliberated on and then back to fesco. But... if it's that crucial, you can send it there :-) 18:36:18 * cwickert needs to leave now 18:36:22 so, that leaves -3, +4 and ? from notting. 18:36:35 mjg59, that's the transition phase for safety reasons... 18:36:48 I still remain -1 18:36:51 mjg59, we don't want to destroy people's systems 18:36:58 Ok so I think what's going to have to happen is you discuss that with notting in the ticket 18:37:05 I haven't been convinced that there's any benefit (other than remote /usr) to this proposal 18:37:11 notting seems to be the swing vote. ;) 18:37:11 And if you can convince him then you get to do this and if you can't then you don't 18:37:19 And it's asking a lot of maintainers 18:37:44 mjg59, he didn't say +/- 0 ... notting said +1 18:37:53 haraldh: He said +1 conditional on something 18:37:58 notting was a +1 in ticket with: "I'm tentatively OK with this, although I have concerns about the implementation on upgrade - I don't want to have a /bin directory with a forest of symlinks inside it, for example." 18:38:10 haraldh: So just settle that and then we're done 18:38:15 notting last week: " i am a moderate +1" 18:38:26 mjg59, ok, will do 18:38:49 I suspect that he'll be ok with things but I also don't want to put words in his mouth 18:38:53 I'd prefer not to second guess him... when we can ask him in ticket. 18:39:02 So let's just do that 18:39:04 I'd really prefer if on such split vote we had clear votes from each member 18:39:18 and not any last week votes or ticket votes with conditionals 18:39:29 if he didn't want it, he would have said -1 ... if he was tentative enough .. he would have said 0 18:39:46 so, action: -4 votes, +4 votes, feature owners will consult with remaining fesco member in ticket. ? 18:39:52 right 18:39:59 t8m: I think we had clear votes from everyone here... 18:40:14 nirik, yes, I am talking about the notting's ticket vote 18:40:32 t8m: you prefer we wait until next week? 18:40:36 nirik, sure 18:40:46 why not have him read this and vote in ticket tho? 18:40:52 I'm fine with him voting in the ticket 18:40:56 Sure 18:41:14 nirik: FPC meets on Wed -- If notting gets back to you before then, could you be sure to file an FPC ticket and mark it meeting? 18:41:17 ok if he clearly votes in the ticket without any conditional then I am fine with that 18:41:38 #action: -4 votes, +4 votes, feature owners will consult with remaining fesco member in ticket. 18:41:55 #action nirik to file FPC ticket for looking over things vs guidelines. 18:41:59 Anything more on this? 18:42:16 * nirik will move on in a sec. 18:42:18 * abadger1999 assumes we'll get quorum in fpc... since no one sent out the new DST adjusted/not adjusted schedule I don't know about that :-( 18:42:29 Yeah, I'm curious who will do the work on changing the hundreds of packages. 18:42:41 thanks for coming haraldh / kay. :) Appreciate it. 18:42:55 t8m: shouldn't that be part of the feature process? 18:42:59 t8m: same as for systemd... maintainers and provenpackagers I guess. 18:43:06 * abadger1999 runs 18:43:09 #topic #693 IPv6 support requirement in Fedora package 18:43:10 .fesco 693 18:43:11 nirik: #693 (IPv6 support requirement in Fedora package) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/693 18:43:14 abadger1999, should probably - that's one of the reasons for my -1 18:43:37 oh good, a slapfight. 18:43:38 * abadger1999 checks if that's one of the critiques on rbergeron's page 18:43:58 ok, so perhaps we should punt this to FPC? 18:44:35 I am not so sure it's a packaging issue. 18:44:53 It is mostly upstream functionality issue. 18:45:08 i have to duck out for a minute, but regardless of whose issue this is, seriously, ipv6 is not an option. 18:45:24 The most we could do is block packages that aren't IPv6-capable. (I'm -1 to that). 18:45:33 I don't think we can really enforce anything beyond that 18:45:54 although the concrete vsftpd example is a slightly more complicated 18:46:01 I think it would be fine to add a "SHOULD" on ipv6 support, but we can't force people to create it if it doesn't exist. This issue just seems like a upstream bug. 18:46:14 :) 18:47:13 so, any proposals? 18:47:17 I think we (where we == "some fesco in the past") supported dwmw2's position. 18:47:26 nirik: huh? as I read it upstream has the feature and we're disabling it by default 18:47:31 if upstream has ipv6 support, the Fedora package must support it too. 18:47:34 oh, is it Monday? 18:47:49 hey, it is. 18:47:50 we do not disable ipv6 support 18:47:51 the package has IPv6 support 18:47:54 in vsftpd 18:47:56 Well the specific case is clearly one where upstream would work but we've broken it 18:48:24 Is there a more general problem or are we really being asked to provide guidance based on one example? 18:48:37 dwmw2: what action are you looking for here? 18:48:52 slap the damn packager and tell him not to be so bloody stupid :) 18:48:55 dwmw2: did you read maintainer replies? 18:49:13 I want the vsftpd package to listen on IPv6 and IPv4 by default, like all Fedora packages should be. 18:49:30 yeah, wow. the ipv6 only stuff is a patch. 18:49:35 dwmw2: even if upstream didn't take that patch? 18:49:41 mmaslano: which patch? 18:49:43 * nirik misread it first 18:49:53 we patched it to break it :) 18:49:54 dwmw2: it's in the ticket 18:50:10 it *used* to work when you just listen on ::. It would accept both IPv6 and Legacy IP connections on the same socket 18:50:40 proposal: in this case tell maintainer to please support listening on both. additionally, file FPC ticket to ask them to add a 'SHOULD: should support both ipv6 and ipv4 connections if support exists' ? 18:50:44 we patched it so that doesn't work any more. You have to run two separate dæmons; one for IPv6 and one for IPv4. Which would be kind of OK if we actually shipped the two initscripts and two configs by default... if a bit daft. 18:51:01 nirik: that's fairly much what I was thinking 18:51:17 * nirik is +1 to that. 18:51:48 mmaslano: you mean the fesco ticket 693? Yes, I read that. Right before I replied, in the ticket :) 18:52:56 other votes? comments? counter proposals? 18:53:11 +1 18:53:18 nirik, why not, +1 18:53:19 +1 I guess 18:53:32 They should support both... at the same time or not? 18:53:49 gholms: define 'at the same time'. 18:54:00 Because the current behavior in this specific case falls within the letter of that rule. 18:54:06 nirik: +1 18:54:07 I don't think it matters if it's from the same dæmon or not. Not from FESCo's point of view. 18:54:15 Okee dokee 18:54:15 #agreed tell maintainer to please support listening on both ipv4 and ipv6 in vsftpd. additionally, file FPC ticket to ask them to add a 'SHOULD: should support both ipv6 and ipv4 connections if support exists' ? 18:54:24 Sorry, everyone 18:54:31 maintainer is listening 18:54:34 would someone like to step up to talk to the maintainer and/or file the FPC ticket? 18:54:40 gholms: well, the current behaviour would only be OK if the package shipped a config for ipv4 *and* a config for ipv6, and initscripts to start the dæmon with both 18:54:41 surely? 18:54:43 ah, welcome skalnik_rh 18:55:18 skalnik_rh: anything to add/input here? 18:55:26 dwmw2: Yes, that makes sense. 18:55:48 gholms: which is one of the potential remedies listed when I originally filed the ticket. 18:56:19 I deliberately kept the technical details *out* of the FESCo issue though; FESCo only really cares about policy. It should be fixed; it's up to the maintainer *how* to fix it. 18:56:19 i wrote everything but only repeat. i'd like to support both possibilities ipv4+6 but also separate 18:56:23 yeah... although it seems kinda a waste of resources. 18:56:54 nirik: two dæmons seems like a waste of resources? Well yes, it's stupid. But at least it's not *broken*. So I wouldn't be whinging to FESCo about it :) 18:56:59 skalnik_rh: so, sounds like the solution is the one dwmw2 suggested... ship two unit files, one for each? 18:57:24 I would prefer to fix the code really, so it can listen on both again. Just drop the offending patch, fix the default config file to listen on IPv6 (which accepts IPv4 too) 18:57:24 nirik, I do not think we need to discuss the concrete solution here 18:57:32 but I don't think FESCo should mandate *which* solution is used 18:57:43 yeah 18:57:47 right. 18:57:47 could we go to next topic, please 18:58:00 was that "a fix should be available for f16" ? 18:58:02 would anyone care to step up to file the fpc ticket? 18:58:04 rather than only in f17? 18:58:35 dwmw2: depends on the solution possibly... 18:58:59 well, maybe the requirement to update f16 would affect the choice of solution :) 18:59:01 ok, I guess I will. 18:59:06 dropping the silly patch *is* feasible in an update. 18:59:14 #action nirik to file FPC ticket about ipv6 support. 18:59:23 shipping a second config+initscript probably is too 18:59:47 dwmw2: if it doesn't change the user experence any, sure, fixing it in stable releases sounds find. 18:59:49 fine. 18:59:57 * nirik will move on to the next topic then... 19:00:01 thanks 19:00:12 #topic #694 Consider sanctions against glibc 19:00:12 .fesco 694 19:00:13 nirik: #694 (Consider sanctions against glibc) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/694 19:00:42 so, we have had no communication from glibc maintainers that I know of here. 19:00:48 jsmith: Anything from you here? 19:00:58 proposal: do not rebase until alpha ;-) 19:00:59 mjg59: Yes... 19:01:13 So, I've been working with the glibc maintainer and his supervisor at Red Hat 19:01:19 mmaslano: counter-proposal: do not allow rebase AFTER alpha :) 19:01:29 sgallagh: damned English 19:01:30 I think we're to the point where we need to restrict his packaging privileges 19:01:57 :( 19:02:14 I'm sad to see it get to this point, but it was one of his supervisors who suggested that it is time 19:02:25 so, reassign the package? 19:02:34 I'll all ears for suggestions on how to best handle this 19:02:36 so now we need to get someone to fall on the grenade. 19:02:46 yeah, thats the difficult part for sure. 19:02:53 ajax, :) 19:02:57 ajax: did you just volunter for that? ;) 19:03:25 drago01, who will be the X maintainer after the grenade explodes? 19:03:29 I suggest we ask Jeff Law if he'd be willing to take the package, at least in the short term 19:03:32 is there any upstream developer community we could talk with and see if anyone there is interested in helping out? 19:03:37 his supervisor's suggestion was to have him (the supervisor who we're not naming for unknown reasons) have signoff for all changes 19:03:42 t8m: ;) 19:03:46 which pretty much means the supervisor is falling on that grenade AFAICS 19:03:54 i'd happily be part of a team looking after glibc, but i don't have anywhere near the time to devote to it full-time. 19:04:04 jsmith: Jeff is the supervisor we're talking about, right? 19:04:17 so, we remove commit for the current maintainer, and add for jefflaw? 19:04:23 nirik: right 19:04:35 pjones: Jeff is one of the people supervising... but there are several supervisors involved. In short, "it's complicated" 19:04:45 I'm happy to do that if it will improve the situation. 19:04:47 jsmith: *nod* 19:05:07 pjones: But yes, Jeff is helping take care of some glibc tasks, and is trying to follow glibc packaging as closely as he can 19:05:23 so what would the workflow look like, then? andreas asks jeff to do a git pull? 19:05:24 * nirik notes law already has commits and approveacls on it. 19:07:05 pjones: something like that I assume... 19:07:11 sounds pretty resolved then. 19:07:44 well, I guess the last action here for us is removing acls for the current maintainer for now? 19:07:49 ue[p 19:07:50 yep. 19:07:55 Yeah, that sounds correct to me 19:08:00 Ok 19:08:06 jsmith: Thanks for working on this 19:08:15 mjg59: No worries -- it was painful, but needed to be done 19:08:23 do we remove them from packager? or just glibc ? 19:08:36 I think just glibc 19:08:45 * nirik notes they are co-maintainer on a few other packages. 19:08:52 Let me also point out that I'm more than willing to reinstate packaging privileges for the maintainer, if/when they agree to start communicating better and working within our packaging guidelines 19:09:46 proposal: remove ownership/acls for current glibc maintainer. 19:09:55 (from glibc) +1 19:09:57 proposal: remove ownership/acls for current glibc maintainer on the glibc package. 19:10:06 nirik: +1 19:10:13 +1 here sadly. 19:10:16 +1 19:10:22 nirik, +1 unfortunately 19:10:39 nirik: +1 19:10:39 #agreed remove ownership/acls for current glibc maintainer on the glibc package. 19:10:45 jsmith: thanks for digging into this. 19:11:07 if nothing else moving on. 19:11:09 Should we make any kind of announcement about this? 19:11:25 I mean, the glibc instability has been biting a lot of packagers/developers for the last few months 19:11:35 sgallagh: Short of informing the packager in question, I'd rather not make a huge deal of it 19:11:37 Clarification 19:11:38 I don't want to publicly shame the packager 19:11:44 Are we just removing his acls from glibc? 19:11:52 (The only package he owns) 19:11:53 abadger1999: and ownership over to law 19:12:03 Or from the packages that he comaintains as well? 19:12:06 https://admin.fedoraproject.org/pkgdb/users/packages/schwab?acls=owner&acls=approveacls&acls=commit 19:12:08 abadger1999: Only glibc 19:12:09 just glibc 19:12:14 Okay. 19:12:20 I'll take care of that. 19:12:24 Given that this is a matter of public record now, I don't think we need to say anything else 19:12:24 thanks abadger1999 19:12:35 yeah, I don't think we want/need any announcement. 19:12:53 #topic #695 Recommend 64-bit download by default 19:12:53 .fesco 695 19:12:54 nirik: #695 (Recommend 64-bit download by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/695 19:13:12 +1 from me. Lets move incrementally into the current day. ;) 19:13:25 +1 from me as well 19:13:31 +1 19:13:37 Given that even Atom is 64-bit now 19:13:45 ? 19:13:46 even arm! ;) 19:13:50 I don't care. I think many people have netbooks, which stil needs i686 19:13:53 Southern_Gentlem: fire away 19:14:18 why does there have to be one default why not point at both the 32 and 64 bit 19:14:47 well, it's hard to present that choice I think in a way that everyone understands. 19:14:48 we get at least 10 questions a day in #fedora which one should i download 19:15:03 Southern_Gentlem: and you think offering more choices will _reduce_ that number? 19:15:19 no but at least we have them coming and asking 19:15:31 yeah please its 2011 already ... lets move on 19:15:39 then i have difficulty connecting your two statements. 19:15:44 what does the x86_64 media do when you boot it on a 32bit platform? 19:15:48 Did the message from Neville Cross get read by people here or did it only go to the FAB list? 19:15:53 nirik: it complains on boot 19:15:58 nirik: prints a message saying it won't boot, last i checked 19:16:06 it would be easy for the website team say i686 (32bit for older machines) x86_64 (new machines 64bit 19:16:15 define old and new 19:16:22 64bit has been around since 2003 19:16:31 yes, but could it instead say: "You need the 32bit media, sorry" at least? 19:16:40