17:01:13 #startmeeting 17:01:17 jds2001: just do a #startmeeting, then #chair bpepple dgilmore dwmw2 jwb notting nirik sharkcz jds2001 j-rod 17:01:25 then a #meetingtopic FESCo meeting 17:01:33 #chair bpepple dgilmore dwmw2 jwb notting nirik sharkcz jds2001 j-rod 17:01:38 then use #topic for each item 17:01:48 cool. 17:01:58 #meetingtopic FESCo meeting 2009-06-12 17:02:13 * dgilmore is here 17:02:48 alright, just a reminder I'm dropping off the planet next week. 17:02:58 * jds2001 will be in the middle of a lake :) 17:03:19 hopefully in a boat. ;) 17:03:26 nirik: indeed :) 17:04:00 so anyone volunteer to chair the meeting and send out the agenda? 17:04:25 * nirik can do it. 17:04:43 awesome. 17:05:15 #action nirik will chair next week's meeting 17:05:41 * nirik notes commands are now at http://wiki.debian.org/MeetBot (it's now named 'meetbot') 17:05:42 also, a reminder that elections are open. Go vote :) 17:06:11 And lastly on the admin front, the retrospective meeting.... 17:06:24 #info Please go vote in FESCo, Board and f12 naming elections. 17:06:25 who wants to attend? I'll be there, we need one more. 17:06:44 jds2001: when is it? 17:06:58 next tuesday, at 2PM EDT 17:06:59 Tuesday at 10AM EDT 17:07:09 erm, 10AM. i can't read. 17:08:19 * nirik can't make that I don't think. Have some stuff tuesday morning. ;( 17:08:31 i can go, but if someone else is chomping at the bit... 17:08:46 * dwmw2 on jury duty this week and next, so not very available 17:08:53 I'd be willing to do it 17:09:36 k, shall we say j-rod is gonna do it? 17:09:56 sounds good. 17:10:04 #action j-rod will attend the F11 release retrospective meeting 17:10:26 onto the tickets 17:10:37 #topic EOL date for F-9 17:10:37 now if that could automagically feed an event to a caldav server and sync to my iphone... 17:10:46 .fesco 160 17:10:50 jds2001: #160 (Announce EOL date for F-9) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/160 17:10:54 * j-rod enters it manually for the time being 17:11:31 10th is fine with me. 17:11:31 * bpepple has no problem with the proposed F-9 EOL date. 17:11:38 seems reasonable 17:11:41 worksforme 17:11:46 jwb notes that due to the July 4 holiday, that last week will be full of updates. If there are push issues, we might not get em all. 17:11:53 f13: does the 10th work for you for EPL of F-9? 17:11:56 works also for me 17:12:14 * dgilmore notes that its ok with him 17:12:26 fine here too. 17:12:32 ok 17:13:11 #agreed EOL date for F-9 will be 2009-07-10 17:13:31 #topic Milestone adjustment proposal 17:13:35 .fesco 162 17:13:38 jds2001: #162 (Milestone Adjustment Proposal) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/162 17:14:04 has there been any feedback on lists or wiki? 17:14:15 * nirik just sees one 'sounds fine to me' comment on the discussion page 17:14:25 yeah, haven't seen much 17:14:54 +1 here, just naming changes to make it more sane. 17:15:04 this is the most self-contained and implementable proposal from the FAD this week 17:15:38 * jds2001 wishes he could have been there. Too many conflict 17:15:40 s 17:15:41 +1, works for me 17:15:44 +1 17:15:48 i strongly suggest fesco members read all the proposals in https://fedoraproject.org/wiki/Category:Proposals and comment 17:15:49 seems fine to me. 17:15:51 +1 to this one 17:16:06 +1 17:16:07 +1 here also. 17:16:28 #agreed proposal at https://fedoraproject.org/wiki/Milestone_Adjustment_Proposal is accepted. 17:16:36 +1 seems fine things change so much between alpha and beta 17:17:02 #topic F-9 branch for olpc-kbdshim 17:17:09 .fesco 163 17:17:13 jds2001: #163 (Allow F-9 branch for olpc-kbdshim) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/163 17:17:26 they want this for existing olpc users. 17:17:36 who use the f-9 fedora packages. 17:17:38 yep 17:17:54 * nirik wonders what they will do when f9 is eol? 17:18:05 good question. 17:18:05 -1 from memory it wont beavailable to OLPC G1G1 users as the yum repos point at olpc specifci ones 17:18:06 is that branch continuing to be supported some other way? 17:18:24 dgilmore: didn't they point to koji? 17:18:50 * nirik notes that olpc uses their own weird update thing, not yum by default. 17:18:52 nirik: for awhile yes 17:19:19 perhaps we could ask what users this would help with in the ticket? as it's unclear? 17:19:23 nirik: but last i knew it was moved to olpc ran infrastructre that was updated by a script mirroring koji 17:19:24 or is the submitted on irc? 17:19:46 .fasinfo cwickert 17:19:48 jds2001: User: cwickert, Name: Christoph Wickert, email: fedora@christoph-wickert.de, Creation: 2005-09-18, IRC Nick: cwickert@irc.freenode.net, Timezone: Europe/Berlin, Locale: de, Extension: 5100271, GPG key ID: 1999A427, Status: active 17:19:50 jds2001: Approved Groups: cla_done fedorabugs packager ambassadors cla_fedora gitnodoka gitspin-kickstarts provenpackager 17:19:52 jds2001: Unapproved Groups: None 17:20:11 he *was* on irc...perhaps he left for the evening 17:20:15 well, he was reviewing the package... the request was from the submitter really. 17:20:25 * dgilmore is verifying where XO's point at for updates 17:20:35 * nirik waits for bugzilla to try and load 17:20:42 * dgilmore olso notes yum was not historically recommended by olpc 17:21:08 what was? the gui activity installer thingy? 17:21:33 'olpc-update' I think... 17:21:38 which basically rsynced a new image. 17:21:42 oh, right. 17:21:51 how quickly I forget :) 17:21:54 .fasinfo pgf 17:21:55 nirik: User: pgf, Name: Paul Fox, email: pgf@laptop.org, Creation: 2009-06-05, IRC Nick: pgf, Timezone: US/Eastern, Locale: en, Extension: 5131621, GPG key ID: , Status: active 17:21:58 nirik: Approved Groups: cla_done fedorabugs packager cla_fedora 17:22:00 nirik: Unapproved Groups: None 17:22:50 * nirik summons pgf 17:23:28 hey there. We are looking at that F-9 branch request... 17:23:39 i figured. :-) 17:23:40 .fesco 163 17:23:45 nirik: #163 (Allow F-9 branch for olpc-kbdshim) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/163 17:23:57 can you tell us which olpc users would be able to use that f-9 package? 17:24:27 all of them. well, those running fedora with access to a yum repo. 17:24:53 how many upgrade via yum? and does that point to f-9 fedora repos? koji repos? your own repo? 17:24:54 the G1G1 images dont have yum pointed at F-9, right? 17:25:13 jds2001: they actually do with a massive exclude line 17:25:25 but yum update fails misserably 17:25:56 perhaps my request was misguided. from the yum output on my XO, i thought it would Just Work. perhaps not? 17:26:11 pgf: yeah, thats what we are wondering... if it matters at all in the end. ;( 17:27:27 is there a way to tell easily? i mean, i can do things like install "dialog" via yum, and i know OLPC didn't build that specially. 17:27:48 pgf: not sure. ;( Should we table this and try and find out? 17:28:12 pgf: how will users know to install the package 17:29:41 dgilmore: well, that's a good question. i guess i was primarily thinking of those that are "in the loop", on either the olpc lists or the olpcnews forum. and it might make it easier for deployments, which often do custom releases, to use it if they did find out about it. 17:30:58 this isn't a critical thing at all. i just figured that because there was no F10 for the XO, that maybe an exception made sense (assuming it works). 17:31:35 pgf: ok. i guess i wont really hurt 17:32:16 I don't object if it will help anything... but it's unclear to me if it will or not. 17:32:36 well dgilmore said they are pointed at f-9 17:32:56 so yum install olpc-kbdshim should work. 17:33:34 even if yum update barfs 17:35:00 doesn't seem like it can possibly hurt anything 17:35:01 just do it 17:35:26 pgf: is this an exception, or the beginning of a list of exceptions? 17:35:40 ah, good question... 17:36:00 yeah, if there's going to be a stream of them, would have to reconsider... 17:36:15 i think this is an exception. 17:36:33 pgf: what happens when f9 is end of life? you guys have some way to keep maintaining those installs? or that should be EOL and move to the newer releases? 17:36:54 pgf: ok. +1 then 17:37:14 we don't have tight control over what the deployments do of course. but we're working on F11. 17:37:31 we just don't have the resources to track every release. 17:37:37 yeah. 17:37:40 +1 here, with the caveat that the branch won't be updateable anymore in a month... but at least there will be a package available for those users. 17:37:56 so, yeah, +1 from me too given that 17:37:58 +1 here 17:38:00 +1 here too, the reasons make sense 17:38:12 +1 17:38:21 +1 17:38:51 #agreed olpc-kbdshim may have a branch for F-9, with the understanding it won't be updateable in a month. 17:38:55 thx pgf :) 17:39:06 thanks! glad i was around... 17:39:35 pgf: go ahead and set fedora-cvs again there and I will do it on my next cvs pass. 17:39:53 #topic EPEL steering committee review 17:39:53 nirik: okay. 17:40:01 .fesco 164 17:40:06 jds2001: #164 (EPEL Steering committee review) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/164 17:40:22 do we have reps from epel steering committee here today? 17:40:25 I am here 17:40:31 * nirik is here. 17:40:33 I didn't know about this til this moment 17:40:40 * nirik puts on multiple hats. 17:40:54 ok I agree with the above. 17:41:10 I agree things have been stagnating in EPEL land. How can we revive them? 17:41:17 I have gone a crappy job since Novemebt 17:41:22 smooge: it's pretty much a verbatim copy of what was on epel-devel. 17:41:28 FYI, I think EPEL is much more a SIG than a Project (to use our terms) 17:41:39 smooge: i added it late today 17:41:42 smooge: it's not just you. :) 17:41:47 I am catching up with that.. I am trying to get out of a job this week so have skipped 99% of my email 17:42:18 * nirik is happy to step aside, try and do meetings again, or whatever. 17:42:44 The issues are: 1) People who are interested in it are on 8-12 hour difference schedules. 17:42:49 we need more people interested, more community. I think a lot of people are just waiting for koji/bodhi. Perhaps we can try and get people involved there to speed up that transition? 17:42:53 getting everyone together is a problem. 17:43:54 nirik: im going to hack together a way to do pushes from koji and try and switch epel to koji next weekend 17:44:04 2) we have an odd infrastructure that should be fixed Real Soon Now* but the RSN has been so long people drifted off. 17:44:06 I've tried to get regular meetings going several times. ;( 17:44:07 but bodhi still needs doing 17:44:54 dgilmore: koji can distribute signed packages, no? 17:45:03 many of the orig folks wandered off as well (perhaps things were going well enough they just thought it was low priority?) perhaps they got busy and didn't have time anymore, not sure. 17:45:14 jds2001: mash can make repos of signed packages 17:45:21 dgilmore: that would be great. Let me know if I can do anything to help. 17:45:56 jds2001: ill need to make some mash configs run sign_unsigned.py and have a way to move packages around 17:46:20 dgilmore: will there be a epel-releng1 box to mash on? 17:46:28 will epel_signers be able to push using this? 17:46:29 im going to propose that builds only land in buildroots when things go to stable 17:46:36 nirik: there will be 17:46:50 ok. 17:47:05 so there will be need to request tagging into buildroot override tags 17:47:33 right. If we do that I would propose a trac instance to track those requests. 17:47:45 such as rel-eng@? 17:47:54 anyhow, what can fesco do to push epel back into more active mode? 17:48:16 well I can make a trac instance :) 17:48:17 notting: yeah. Does rel-eng want to take on the tasks they do for fedora for epel too? 17:48:36 for the non-technical talk.. I think EPEL needs a good rethink and relook with the people current in it. It needs to also be ready for EL-6 and needs better take from our 'downstream' so that we aren't colliding as much 17:48:50 i think fesco needs to get regualr updates as to whats going on 17:48:57 even if that is nothing new 17:49:17 nirik: perhaps with an epel volunteer stepping up to join? :) 17:49:30 dgilmore: ok, why in epel and not other sigs? or are you supposing epel is a project ? 17:49:40 (just saying that rel-eng at least already has policies & procedures for this) 17:49:49 nirik: secondary arches need to do it also 17:49:51 notting: well, I don't mind tagging packages, doing signs and pushes at all. 17:50:09 * nirik is fine with regular repedative tasks... cvsadmin has taught me that well. ;) 17:50:51 dgilmore: so, it sounds like I should try and get regular meetings going again then? although I have no idea if it will work any better this time than the last 2. 17:51:24 nirik: i think that would be a help 17:51:27 dgilmore: yeah, a monthly epel report would be nice 17:51:38 nirik, I should be better off starting next week on being at meetings and doing reports 17:51:39 nirik: most of the mail on the mailing list is the push emails 17:51:57 and would be able to help you get things done 17:51:58 dgilmore: yeah, but I think many people are just happy with it the way it is... 17:51:59 general talking on the mailing list seems to be down a bit also 17:52:17 there is only one really important item I know of that should get addressed. 17:52:20 nirik: that may well be the case. if so it is what it is 17:52:30 openjdk 17:52:48 it cant be there for i386/x86_64 17:52:53 yeah 17:52:55 the plugin could be 17:53:03 it can be there for ppc 17:53:06 dgilmore: agreed. However it still is. 17:53:21 it should be removed for now I guess. 17:53:29 nirik: likely yeah 17:53:34 s/for now/forever :) 17:53:43 well, the plugin can be there. 17:53:52 jds2001, or until downstream drops it 17:53:53 jds2001: RHEL 5.3 nly has it on i386 and x86_64 17:53:59 ppc can remain 17:54:02 * nirik sighs at rhel failure on this one. :( 17:54:03 as can the plugin 17:54:07 right. 17:54:19 since the plugin is not shipped on rhel 17:54:24 dgilmore: ppc has no jit. ergo openjdk isn't really useful there 17:54:36 perhaps someone in fesco could poke the rhel people to push a rhel update. They have ignored/refused to so far. 17:54:37 the issue as I see it is we need a better 'netmask' with RHEL so we can get stuff out sooner 17:54:45 notting: it still has shark/sero its not as useful but still is 17:54:52 dgilmore: not in rhel, it doesn't 17:54:55 smooge: we need some interface there yes. 17:55:12 * nirik has no idea how to find such an interface. 17:55:48 i thought that was the sort of thing that spot was to facilitate??? 17:55:49 nirik, me either. I will bring it up if I see any RHEL people soon 17:56:03 jds2001, spot is a very very busy person 17:56:28 indeed he is. 17:56:35 and I think we haven't pinged him on it lately etc 17:56:38 ... who is on vacation 17:56:57 spot gets vacation? shocker! :D 17:57:06 I think we asked stickster a long time back about finding someone, but no one ever stepped up for it. 17:57:29 it's not really a vacation. That's just what they call it when he escapes from his cage 17:57:30 in this case I guess we just need to find a bad openjdk security bug to get them to update. 17:58:19 anyhow, I can try and revive meetings, we can add a trac instance to store tickets? (or should we reuse rel-eng's trac) 17:58:38 * nirik notes the announce and packages-announce mailing lists are ready for bodhi. 17:58:45 i would keep it separate..... 17:58:54 nirik there has to be a few.. Sun released 2 or 3 patches ot thier closed version since that branch 17:59:17 nirik I think we should get our own trac 17:59:25 f13: you ok with EPEL stuff in rel-eng's trac instance? 17:59:38 I don't want to break f13's workflow 17:59:42 oh type slow 17:59:57 * jds2001 makes epel-releng 18:00:00 I don't mind 18:00:08 jds2001: hang on please. 18:00:14 * jds2001 hangs on :) 18:00:19 as long as we get people to help with doing the tickets 18:00:37 f13: if you can add a EPEL component and make me 'kevin' the default assignie? and/or anyone else who steps up 18:00:55 I could also make an epel list the default assignee 18:01:09 which would allow the ticket notifications to go to a list and somebody from EPEL could pick it up and run with it 18:01:11 f13 oooooh 18:01:17 (which is how we do it now) 18:01:27 f13: probably easiest 18:01:30 f13: sounds fine to me. That would be epel-devel then. 18:01:46 * nirik is listadmin for that list, so let me know what address to allow to post. 18:01:48 ok. Can you file a ticket for me to do the admin work? (so as I don't forget it) 18:02:00 f13: sure. 18:02:08 * smooge needs to get nirik to give him the password again so he can help cut down the spam work nirik does daily 18:02:30 f13: should epel use a different machine for mashes, etc? or would that be something that could exist on existing releng machines? 18:02:43 nirik: it needs ist own 18:02:45 that's a good question 18:02:50 different keys etc 18:02:57 it probably needs it's own, but we'll still be contending for the same filestore resources 18:03:17 we actually need to get our staging box up and running to see how bad multiple concurrent composes really hurts things 18:03:26 ok, just curious. 18:04:02 f13, is that a task for fedora-admin? I am just checking to see who is supposed to help you with that? 18:04:22 I think the guest is created, releng just has to go poke at it 18:04:26 josh was doing most the leg work there 18:04:46 f13, ok. 18:05:06 ok so to summarize EPEL stuff 18:05:16 1) monthly reports are needed 18:05:33 2) trac will be Rel-eng to cover build items 18:06:00 3) need to find a RH contact to deal with crossed over packages 18:06:19 4) weekly meetings need to be done and figured out how to do 18:06:33 5) FESCO will help as needed to get this going again 18:06:47 ? overstated missed stuff? 18:07:12 * smooge realizes the 4 cups of coffee and doughnuts has kicked in 18:07:15 * nirik isn't sure what fesco can do off hand, but welcomes any help. 18:07:40 .releng 1926 18:07:43 nirik: Ticket #1926 (task created): setup epel to handle rel-eng type stuff || Ticket #1925 (task created): please tag opal-3.6.2-2.fc11 into F11 build override || Ticket #1923 (task closed): Remove package : childsplay_plugins || Ticket #1924 (task created): Buildroot override || Ticket #1923 (task created): Remove package : childsplay_plugins || Ticket #1918 (defect closed): bodhi failed to move (9 more messages) 18:07:51 huh. weird. 18:08:16 that shouldnt happen. 18:08:22 oh well 18:08:25 #agreed 1) monthly EPEL reports are needed 18:08:34 #agreed 2) trac will be Rel-eng to cover build items 18:08:43 #agreed 3) need to find a RH contact to deal with crossed over packages 18:09:00 #agreed 4) weekly meetings need to be done and figured out how to do 18:09:07 #agreed 5) FESCO will help as needed to get this going again 18:09:24 sounds good to me. 18:09:56 #topic spring ships internal copies of 7Zip and other things 18:10:05 .fesco 165 18:10:09 jds2001: #165 (spring ships internal copy of 7zip and others) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/165 18:10:12 i created a bug for this 18:10:38 bug 505636 18:10:39 Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=505636 high, low, ---, gauret, NEW, spring contains copies of external libraries 18:10:59 so what should we do? 18:11:10 nothing else they request an exception? 18:11:11 i happened to poke at it today because it was trying to compile as i686 on sparc 18:11:13 just reiterate that external libraries are not allowed in packages? 18:11:38 jds2001: probably did nt need a fesco ticket. unless he refuses to fix it 18:12:01 no worries. Keep us posted. 18:12:33 #topic fedora-release versioning proposal 18:12:39 .fesco 161 18:12:44 jds2001: #161 (Proposal for fedora-release version-release naming for rawhide) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/161 18:12:56 I would like rel-eng input on this one. 18:12:59 * jds2001 wonders what problem we're trying to fix here. 18:13:02 i honestly dont like it because i feel its confusing 18:13:14 I think it makes sense, but is mostly cosmetic 18:13:29 i think 10.92 is clearer than 11 but that rpm says its 11-0.1 18:13:52 hm... i don't like it because it would mean new tarballs would all be fedora-release-11.tar.gz 18:14:09 true. 18:14:10 I was just reading this 18:14:17 notting: wee already have that problem 18:14:18 the upstream really is 10.92 or whatever 18:14:21 its very common for prerelease things to be the old release + .90 .91 etc 18:14:22 It's not just clarity, but also that the version part changes during the development cycle. 18:14:33 its much less common to operate as proposed 18:14:37 notting: the tarball is really effed. as soon as we do 10.92-2 we've re-spun the same tarball anme 18:14:38 name 18:14:41 mysql being an exception 18:14:45 so here is my thought 18:14:49 dgilmore: many packages do. the kernel does 18:15:02 given the FAD proposals, the rawhide fedora-release would be the same and never really changing, i'td just be rawhide. 18:15:21 nirik: thats a packaging issue not a upstream one though 18:15:25 so what version is it then? 18:15:33 when we branch for a release, then we could do a fedora-release-12-0.1 and fedora-release-12-0.2 until we get to RC and make it fedora-release-12-1 18:15:50 fedora-release-20090612gitXXXXXX 18:16:30 f13: do you understand the problem this is trying to solve? 18:16:32 when does a fedora-release-13-0.1 appear? 18:16:37 f13: if so can you explain it to us 18:16:40 dgilmore: I don't 18:16:51 dwmw2: i dont either 18:16:54 what I _would_ like to solve is the problem of switching to/from rawhide 18:16:58 nirik: when we branch for F13 18:17:09 I just had to go edit /etc/yum.repos.d/rpmfusion-free-rawhide.repo to disable it 18:17:11 dgilmore: mostly I think it's to do with using $releasever variables 18:17:16 and re-enable the normal rpmfusion-free repo 18:17:23 having _that_ happen automatically would be nice 18:17:29 depending on the fedora-release package that's installed 18:17:50 dwmw2: rpmfusion-release could update too, no? 18:17:51 * nirik wonders if this is a fesco item. Shouldn't it be solved by the maintainer of the fedora-release package? :) 18:17:55 dwmw2: rpmfusion could symlink 11.90 to devel 18:18:18 dgilmore: fedora-release was set up so that we don't follow rawhide; we stay on 11 18:18:24 * nirik wishes rawhide was a different (sub)package entirely. Then all the people who enable it by mistake wouldn't 18:18:29 dwmw2: right 18:18:42 oic, yes -- then they wouldn't have to have the separate rpmfusion-free-rawhide repo config at all. 18:18:48 dwmw2: i guess i dont understand whyat your getting at 18:19:10 nirik: was kind of my thought, I didn't notice it was a FESCo proposal until 2 minutes ago 18:19:33 so, I see advantages, but I think it's going to have to be carefully thought out. 18:19:43 f13: you wanna table it for later then? 18:20:04 yeah, I need some time to think about it, particularly in light of the FAD proposals 18:20:10 dgilmore: it sucks that I have to disable the rpmfusion-free repo and enable rpmfusion-free-rawhide manually, when I switch to rawhide. And then edit them both again when rawhide becomes f11 18:20:50 #agreed fedora-release versioning proposal is tabled until rel-eng can think about it more. 18:21:11 that's all I had, but I do have one more item. 18:21:32 If the rawhide repos were stored in releases/nn then you wouldn't have to have the rawhide repo files at all. 18:21:33 #topic LVM and provenpackager 18:21:35 * nirik checks jds2001 for synax 18:21:44 syntax even 18:21:56 dwmw2: right with a symlink rpmfusion could avoid that for users 18:22:17 so I've pinged this ticket several times, and gotten no response. 18:22:39 honestly I don't really think it's FESCo's duty to make the management of secondary repos easier. That's more of the secondary repo's problem. 18:22:40 .fesco 124 18:22:45 jds2001: #124 (Re: Packages with closed ACL's - LVM related items) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/124 18:23:08 f13: i agree. and i don't think its a hrd thing for them to fix 18:23:13 f13: no, but it's sane to think about the issue when we're changing things. 18:23:34 so I was going to ping it again, but I wanted some teeth behind it this time. 18:24:09 nah, just open the damn package 18:24:17 how about ask for a response, if nothing by next meeting, packages will be opened. 18:24:20 so I was wondering the posistion on "if you don't respond in 2 weeks, these packages will be opened. The rest of the distro has been for awhile" 18:24:29 nirik: you 18:24:35 are thinking what I was. 18:24:43 * nirik is fine with 2 weeks too. 18:24:45 jds2001: i think we just open the acls 18:24:54 I just wanted to make sure everyone was cool with that before I unilaterally said/did something. 18:25:24 * bpepple is fine with 2 week chance to respond. 18:25:26 * sharkcz agrees the position 18:25:37 worksforme 18:25:38 * notting is fine with the position. 2 weeks seems a bit long, but ok 18:25:45 I'd settle for 2 weeks warning. Now would be better. 18:26:08 i think we just do it now 18:26:13 coo 18:26:20 i think they have had enough warning already 18:26:46 #agreed jds2001 will ping ticket 124 again, and if no repsonse in 2 weeks, open ACL's. 18:26:55 anything else? 18:27:07 #topic open floor 18:27:07 arch support 18:27:09 I have one item 18:27:29 j-rod: ? 18:27:30 we went i586 for f11, and talked about going i686 in f12 18:27:33 then nirik 18:27:48 j-rod: it is what we did agree on when we went i586 18:27:49 #topic arch support for F12 18:28:06 do we need a feature page? i can write one up for next week 18:28:10 does this include the 'x86_64 kernel on 32bit installs/userspace' ? 18:28:18 so if we agreed to go i686 for f12, we should make that change sooner than later 18:28:29 yeah, I would think a feature page and asking for comment would be good before making any decisions. 18:28:32 j-rod: sooner 18:28:54 does this end up hurting olpc? 18:29:21 dont think so 18:29:21 aren't they more or less branching from F11? 18:29:37 currently yeah. 18:29:41 for now, yeah, but they are going to have more versions :D 18:29:49 (one would hope) 18:29:59 and the I *think* the new 1.5 hardware supports full i686 18:30:06 but i thought we went through this 18:30:15 i686 stuff currently runs on the XO, no? 18:30:18 glibc? 18:30:30 jds2001: it's i686 without CMOV or something weird. 18:30:41 j-rod: appears to. sse2, even. 18:30:55 yeah, the 1.5 hardware is a Via C7-M proc 18:31:13 so, cmov, sse2/sse3, nx etc. 18:31:46 so, what do we loose dropping i586? just those lonely pentium users? 18:31:56 the geode is i686 compataible it meets all the specs 18:32:03 but it presents itself as a i586 18:32:07 nirik: pretty much 18:32:11 and needs mass rebuild again in f12. 18:32:13 and some via users 18:32:22 nirik: doesnt need a mass rebuild 18:32:27 (which we might need anyhow if lzma rpm support is needed) 18:32:29 oh? 18:32:42 things would be ok with some i586 bits 18:32:57 but we could decode that we want i686 for everything 18:34:21 also, if we do i686, we may do i686+ 18:35:12 and i586 and the lesser i686 can be resurrected as a secondary arch 18:35:23 there are benefits to going to sse2+ -only (which would drop support for pentium pro/2/3, and 32-bit athlon) 18:36:26 notting: right if we do it now we can give time for people interested to do i586 p2 p3 p pro athlon as a secondary arch 18:37:02 any sort of change that drops platform support would need to be fed to the marketing machine, such that they can prepare the userbase. 18:37:38 jds2001: it needs to be done now if its going to be done 18:37:49 yep 18:38:02 ok, i'll do the feature page, start the list flamewar^Wdiscussion, and we can discuss next week 18:38:05 we've already planted the seed, but yeah, we need to do this ASAP... 18:38:08 cool 18:38:29