=================================== #fedora-meeting: FESCO (2014-08-27) ===================================

Meeting started by nirik at 17:00:10 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-08-27/fesco.2014-08-27-... .

Meeting summary --------------- * init process (nirik, 17:00:10)

* #1178 Fedora 21 scheduling strategy (nirik, 17:04:02) * LINK: https://fedorahosted.org/fesco/ticket/1178 (nirik, 17:04:02)

* #1322 F21 Changes - Progress on Changes Freeze (nirik, 17:07:35) * LINK: https://fedorahosted.org/fesco/ticket/1322 (nirik, 17:07:35) * will update changes for next meeting and see if any are in danger. (nirik, 17:10:34) * server database role probibly will be retargeted at f22 (nirik, 17:10:46)

* #1332 retire orphan packags after 4 weeks instead of once per release (nirik, 17:12:26) * LINK: https://fedorahosted.org/fesco/ticket/1332 (nirik, 17:12:26) * AGREED: allow retiring of non stable release packages after they are orphaned for 6 weeks. (+7,0,0) (nirik, 17:26:33)

* #1336 - 32 bit ppc support (nirik, 17:26:42) * LINK: https://fedorahosted.org/fesco/ticket/1336 (nirik, 17:26:43) * LINK: https://fedoraproject.org/wiki/Architectures (nirik, 17:35:57) * AGREED: any arch that wants to call itself fedora needs to build up and host their own infrastructure, along with building up enough packages to show that they can do a working remix of fedora. Then request that FESCo consider them as a secondary arch (+7,0,0) (nirik, 17:41:06)

* Next weeks chair (nirik, 17:41:15) * sgallagh to chair next week (nirik, 17:44:48)

* Open Floor (nirik, 17:45:21) * LINK: http://pootle.translatehouse.org was mentioned... but anyhow, I am ok with them doing what they think is best. The history with transifex makes me sad to be moving things... oh well. (nirik, 17:50:28) * AGREED: FESCo is fine with https://fedoraproject.org/wiki/L10N_Move_To_Zanata ; please schedule the upstream project migration to happen after F21 final release is approved. (+7,0,0) (nirik, 17:53:16)

Meeting ended at 18:01:30 UTC.

Action Items ------------

Action Items, by person ----------------------- * **UNASSIGNED** * (none)

People Present (lines said) --------------------------- * nirik (96) * dgilmore (50) * jwb (44) * mitr (31) * sgallagh (25) * thozza (23) * t8m (20) * jreznik_ (9) * zodbot (8) * kalev (8) * mmaslano (0) * mattdm (0) -- 17:00:10 <nirik> #startmeeting FESCO (2014-08-27) 17:00:10 <zodbot> Meeting started Wed Aug 27 17:00:10 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:10 <nirik> #meetingname fesco 17:00:10 <nirik> #chair dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:10 <nirik> #topic init process 17:00:10 <zodbot> The meeting name has been set to 'fesco' 17:00:10 <zodbot> Current chairs: dgilmore jwb kalev mattdm mitr mmaslano nirik sgallagh t8m thozza 17:00:32 * sgallagh is doing double-duty in the blocker bugs meeting right now 17:00:34 <kalev> hello hello 17:01:07 <thozza> hy 17:01:09 <thozza> hi 17:01:23 <jwb> i'm in a meeting i can't get out of. apologies, it was supposed to be over but i will be late 17:02:03 <mitr> Hello 17:02:48 * nirik will wait another min for more folks to arrive 17:03:50 <nirik> ok, I guess we have quorum... barely. ;) 17:04:02 <nirik> #topic #1178 Fedora 21 scheduling strategy 17:04:02 <nirik> .fesco 1178 17:04:02 <nirik> https://fedorahosted.org/fesco/ticket/1178 17:04:04 <zodbot> nirik: #1178 (Fedora 21 scheduling strategy) – FESCo - https://fedorahosted.org/fesco/ticket/1178 17:04:08 <nirik> so, we should be going into freeze today. 17:04:19 <nirik> I see jreznik_ already bumped the schedule a week. 17:04:34 <nirik> Do we want to do anything here? or leave it as it is? 17:04:34 * jreznik_ is here 17:05:05 <jreznik_> nirik: yeah, I bumped it - it was the only way how to make sure we have at least somehow correct dates on web (it's automatically parsed) 17:05:13 <jreznik_> do we need any other corrections? 17:05:28 <t8m> Hi all, I am sorry for being late 17:05:29 <jreznik_> I don't think anybody raised any big concern 17:05:59 <nirik> yeah, I'm ok with it as it is... note that more slipping would drop us into thanksgiving for release... 17:06:01 <nirik> (in the us) 17:07:18 <nirik> ok, will move on then if no one has changes here... 17:07:35 <nirik> #topic #1322 F21 Changes - Progress on Changes Freeze 17:07:35 <nirik> .fesco 1322 17:07:35 <nirik> https://fedorahosted.org/fesco/ticket/1322 17:07:37 <zodbot> nirik: #1322 (F21 Changes - Progress on Changes Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/1322 17:07:40 <jreznik_> I'm aware of it and there's possibility we will collide with thanksgiving 17:07:42 <nirik> jreznik_: any news here? 17:08:00 <jreznik_> nirik: no news but as we are now frozen, I'll do another round of nagging 17:08:14 <jreznik_> I'm just updating ChangeSet with changes 17:08:16 * dgilmore is here 17:08:25 <nirik> anything we need to punt to f22? 17:08:56 <sgallagh> nirik: Arguably this would be the point where we punt the DB Role for Server. 17:09:17 <nirik> yeah, I just have had no time to look into it... ;( 17:09:18 <jreznik_> sgallagh: if yes, let me know 17:09:21 <nirik> I'd be ok doing that. 17:09:36 <nirik> which of course doesn't mean we can't work on it... 17:10:00 <jreznik_> with vacations, I hadn't much time for changes, will make sure it's in a good shape for the next week 17:10:19 <nirik> ok. 17:10:21 <sgallagh> Well, it's not going to be on the Alpha DVD, that's for sure. 17:10:34 <nirik> #info will update changes for next meeting and see if any are in danger. 17:10:46 <nirik> #info server database role probibly will be retargeted at f22 17:11:05 <nirik> anything else here today? 17:12:26 <nirik> #topic #1332 retire orphan packags after 4 weeks instead of once per release 17:12:26 <nirik> .fesco 1332 17:12:26 <nirik> https://fedorahosted.org/fesco/ticket/1332 17:12:28 <zodbot> nirik: #1332 (retire orphan packags after 4 weeks instead of once per release) – FESCo - https://fedorahosted.org/fesco/ticket/1332 17:12:34 <nirik> so there was some discussion about this on list... 17:12:40 <nirik> but it didn't seem to reach a consensus. 17:13:22 <dgilmore> main reason we dont do it more often traditionally has been that we can not remove things from the GA tree 17:13:34 <dgilmore> which make some of it really difficult to implement 17:13:47 <mitr> Retiring anything from released branches is out of the questino IMHO 17:13:52 * jwb is here now 17:14:04 <nirik> agreed 17:14:06 <sgallagh> Well, in theory we *could* have something like the fedora-release package carry around "Obsoletes:" for packages that are retired. 17:14:14 <dgilmore> but doing rawhide/branched more often I dont see a big issue with 17:14:43 <nirik> sgallagh: that sort of thing has been proposed a number of times and gotten shot down. 17:15:19 <t8m> I think the 4 weeks is slightly too short interval though 17:15:34 <thozza> the 4 weeks period was perceived as too short in general 17:15:38 <thozza> from the discussion 17:15:44 <sgallagh> I also wonder if we could solve this problem better through more automation 17:15:53 <mitr> I’m quite in favor of doing rawhide (not sure about branched) more frequently (not sure about 4 weeks), but that depends on someone implementing the tools and the process. 17:16:11 <sgallagh> The ownership change mails are nice, but maybe also automatically-CC all the dependencies when something is orphaned? 17:16:16 <nirik> I think tyl was offering to work on the tools. 17:16:28 <dgilmore> mitr: i believe till who proposed it is looking at writing tooling to do it 17:16:45 * nirik can't type today, yeah, till 17:16:54 <mitr> nirk, dgilmore: ah. That makes it much better. 17:17:10 <dgilmore> he wanted to make sure it was okay to do 17:17:22 <nirik> so, what time period do we think might be more acceptable? 6 weeks? 8? 17:17:32 <thozza> One of the reasons in the ticket was that we often don't know why the package was orphaned when retiring it 17:17:36 <jwb> i'd say 6 17:17:48 <thozza> there was no mechanism last time I orphaned a package to say why 17:17:56 <thozza> are we going to add this too? 17:18:00 <nirik> there is now. ;) 17:18:07 <thozza> to make the decision easier 17:18:09 <t8m> I'd prefer 8 weeks but 6 is OK 17:18:12 <nirik> when you use fedpkg to orphan it asks you. 17:18:30 <mitr> both 6 and 8 is fine with me, slight preference for 6 17:18:51 <nirik> hum, or perhaps that was just discussed and isn't implemented yet. 17:18:55 <nirik> but I agree we want that too. 17:19:03 <dgilmore> thozza: fedpkg retire now requires a reason 17:19:11 <dgilmore> thozza: and its the only way to retire a package now 17:19:14 <nirik> yeah, but not sure orphan does 17:19:34 <thozza> retire yes, but in the ticket the complain was about orphaning 17:19:35 <nirik> but we could make pkgdb ask. 17:19:45 <dgilmore> orphan doesnt require a reason 17:20:13 <thozza> that what makes the decision if to retire hard based on till's ticket 17:20:17 <thozza> sometimes 17:20:39 <thozza> i think it would be worth of adding a reason also for orphaning 17:20:40 <nirik> well, it means sometimes we would retire because 'orphaned for 6 weeks' 17:20:46 <nirik> which isn't very descriptive. 17:21:28 <nirik> but I guess sometimes we wouldn't really know... old maintainer could just not have time 17:21:44 <jwb> i don't think the orphan reason matters tbh 17:21:59 <jwb> i think "this was sitting there for 6 weeks and nobody cared to take it" is reason enough 17:22:09 <t8m> I suppose main reason for orphaning is that the maintainer does not want to maintain the package anymore 17:22:40 <nirik> or could be they were inactive and their packages were orphaned by fesco, or ... lots of things. 17:22:57 <jwb> nirik, again, doesn't matter. nobody picked it up in the interim 17:23:10 <mitr> jwb: “there is a critical security bug I don’t know how to fix, and upstream hasn’t made a release in 2 years”, or “the last upstream release turned this from a QR code generator into a pony gallery” would be interesting to know about 17:23:12 <t8m> If the maintainer thinks the package is not worth maintaining because it is "bad" he should retire it 17:23:13 <thozza> jwb: I agree, but it can discourage new maintainer from taking the package because he might not know what was the problem with it 17:23:16 <t8m> directly 17:23:29 <thozza> but I agree it it not the thing we have to have 17:23:30 <mitr> t8m: true 17:23:43 <thozza> t8m: I agree 17:23:51 * nirik nods. 17:24:37 <nirik> proposal: allow retiring of non stable release packages after they are orphaned for 6 weeks. 17:24:43 <jwb> +1 17:24:47 <mitr> nirik: +1 17:24:54 <t8m> nirik, +1 17:24:57 <kalev> +1 17:25:23 <dgilmore> +1 17:25:48 <sgallagh> +1 17:26:28 <thozza> +1 17:26:33 <nirik> #agreed allow retiring of non stable release packages after they are orphaned for 6 weeks. (+7,0,0) 17:26:42 <nirik> #topic #1336 - 32 bit ppc support 17:26:42 <nirik> .fesco 1336 17:26:43 <nirik> https://fedorahosted.org/fesco/ticket/1336 17:26:44 <zodbot> nirik: #1336 (32 bit ppc support) – FESCo - https://fedorahosted.org/fesco/ticket/1336 17:27:21 <nirik> so, what do we need to decide here? ;) 17:28:12 <mitr> Actually reading this now, this is “someone might ask FESCo for a decision in the future“ thing? 17:28:16 <dgilmore> how an arch that doesnt want to be maintained by the secondary arch team should be supported if another group wants to 17:28:36 <jwb> simply put: they do it themselves 17:28:40 <dgilmore> mitr: well, its a down the road but highly likely thing 17:28:42 <jwb> (imho) 17:28:58 <nirik> yeah, it sounds like there's no actual work really to look at yet? 17:29:05 <t8m> I don't think there is much to decide. Basically all the concerns with reintroducing ppc32 are quite obvious and if anyone would want to reintroduce it they would have to solve them. 17:29:08 <jwb> i suspect very much that this might be a good precendent for if/when we decide to drop i686 though 17:29:11 <mitr> I _have_ seen a sudden surge in ppc(32) bugs recently, but IIRC nothing to do with composes 17:29:11 <sgallagh> My stance is that they should become a Fedora Remix. End of story. 17:29:16 <dgilmore> the decision can be delyaed 17:29:27 <dgilmore> but some thought on how it should be done I think is needed 17:29:30 <nirik> jwb: could be. 17:29:42 <jwb> t8m, on the other hand, i'd really like to drop ppc32 support from kernel.spec 17:29:43 <mitr> sgallagh: Probably. The case for supporting 32-bit is decreasing every year. 17:29:57 <dgilmore> mitr: there has been no 32 bit ppc composes since f18 17:30:00 <jwb> i've waited patiently to do so, but i'm not interested in waiting longer 17:30:10 * nirik has a ppc32 box. It has F12 I think on it and has been powered off since then. I can't see much use for turning it on personally. ;) 17:30:41 <dgilmore> jwb: im all for it going away 17:30:42 <nirik> dgilmore: install media hasn't been made since f12 I think too right? or around then... 17:30:49 <mitr> Just to be explicit: What about 32-bit userspace on ppc64? Are we supporting that at all? 17:31:00 <t8m> jwb, in theory, if someone came up and said that he would maintain the ppc32 support in kernel, would you accept it? 17:31:08 <dgilmore> nirik: some was made for f18, but no one in the community stepped up to test of fix bugs 17:31:14 <dgilmore> I think it didnt actually work 17:31:21 <t8m> jwb, or you don't want the ppc32 there in any case? 17:31:27 <dgilmore> mitr: no its gone 17:31:42 <jwb> t8m, someone said they were going to. they said that months ago. no ppc32 infrastructure exists still 17:31:57 <jwb> t8m, so if someone showed up and pointed me to a koji instance that was acutally running, i'd add it back in 17:32:13 <dgilmore> jwb: i believe thats the guy that sent an email to the ppc list last week introducing himself 17:32:21 <t8m> jwb, then it is no problem and you can drop it 17:32:33 <jwb> dgilmore, yeah, same guy. still no running infrastructure 17:33:16 <dgilmore> proposal: any arch that wants to call itself fedora needs to build everything on their own, show that they can do a remix of fedora. then request that FESCo consider them as a secondary arch 17:33:25 <jwb> i don't want to get into a pattern of "oh, i'll wait 3 more weeks because someone sent an email" 17:33:33 <nirik> If secondary arch and kernel folks don't see their effort as viable, not sure fesco should override. 17:33:41 <dgilmore> jwb: right, because he sent that email I filed this ticket 17:33:47 <mitr> dgilmore: That sounds like an unexpected overreach/generalization 17:33:57 <dgilmore> so we can say to him this is what you have to do if you want it to happen. 17:34:15 <jwb> mitr, i don't think it is. i think it's a formalization of what has already happened. 3 times now. 17:34:23 <dgilmore> mitr: perhaps. I know there is people working to get Fedora bootstrapped on mips 17:34:42 <jwb> ppc/ppc64 started in my basement. armv7 started at seneca. aarch64 started outside of fedora as well 17:34:44 <t8m> dgilmore, +1 17:34:54 <dgilmore> having something viable and working, i don't think is too much toa sk 17:34:55 <mitr> jwb: Actually, AFAIK in most cases the secondary Koji was maintained by Fedora Infra long before secondary arch had full feature parity. 17:34:57 <dgilmore> to ask 17:35:02 <jwb> mitr, no 17:35:06 <sgallagh> Yeah, I think codifying dgilmore's approach makes some sense 17:35:20 <dgilmore> mitr: none of the secondary koji's are maintained by infra 17:35:27 <mitr> And we've had the ARM debate about whether primary architecture promotion implies other maintainers fixing build failures, which implies that there _were_ build failures 17:35:33 <t8m> mitr, the Fedora Remix does not have to have "full feature parity" to be considered 17:35:45 <t8m> mitr, I don't see anything like this in the dgilmore's proposal 17:35:46 <nirik> dgilmore: I think we have this somewhat already codified. 17:35:48 <jwb> mitr, the bootstrap for all of the arches was started elsewhere. after it was proven somewhat viable and active, hardware was added to the fedora datacenter. none of it is maintained by fedora infra 17:35:57 <nirik> https://fedoraproject.org/wiki/Architectures 17:36:23 <mitr> t8m: I read "build everything on their own" as "all packages that exist" 17:36:28 <dgilmore> the main difference i see in the ppc32 case is that the ppc team does not want to maintain it 17:36:29 <nirik> although it needs updating. 17:36:40 <nirik> yeah, this is a special case I guess. 17:37:29 <dgilmore> mitr: that doesnt have to be the case, none of the arches have all packages that exist in fedora on them 17:37:47 <dgilmore> mitr: there is arm only packages that just do not exist on x86 17:37:47 <t8m> dgilmore, could you replace the 'build everything" with something more precise in your proposal? 17:37:52 <mitr> dgilmore: Good, that was my main objection to that working / the thing I saw as an overreach 17:38:11 <nirik> mitr: infra doesn't maintain really the aarch64/ppc/s390 stuff... I would actually like to start doing so more actively, but right now they maintain their own machines. 17:38:46 <thozza> what about "build everything on their own"/"build selected feature set on their own" ? 17:38:49 <mitr> nirik: My mistake—I always understood “in Phoenix” and “maintained by Fedora infra” to be the same thing. 17:39:29 <nirik> mitr: well, we can get to them and power them off, etc... :) but yeah. 17:39:32 <dgilmore> proposal: any arch that wants to call itself fedora needs to build up and host their own infrastructure, along with building up enough packages to show that they can do a working remix of fedora. Then request that FESCo consider them as a secondary arch 17:39:47 <mitr> thozza: I guess the minimum we want is “bootstrap on their own”, and what we actually want is something in the middle—“build a realistic installable image” 17:40:09 <thozza> mitr: sure, it was just rough idea 17:40:15 <dgilmore> thozza: mitr: really the build everything was more about their infrastructure. hopefully the newer proposal is clearer 17:40:16 <t8m> dgilmore, +1 17:40:31 <mitr> dgilmore: Works for me (… as a default/starting point; someone proposing an arch would probably want to come discuss the specifics in any case). +1 17:40:37 <jwb> +1 17:40:39 <nirik> sure, +1 17:40:42 <dgilmore> mitr: right 17:40:52 <thozza> dgilmore: +1 17:40:57 <sgallagh> dgilmore: +1 17:41:06 <nirik> #agreed any arch that wants to call itself fedora needs to build up and host their own infrastructure, along with building up enough packages to show that they can do a working remix of fedora. Then request that FESCo consider them as a secondary arch (+7,0,0) 17:41:15 <nirik> #topic Next weeks chair 17:41:21 <nirik> who wants the mic next week? 17:41:34 <sgallagh> And by extension, any package removed from Fedora proper that wanted to revitalize itself should have to re-enter through the same process? 17:41:50 <jwb> sgallagh, uh... 17:41:52 <jwb> what? 17:41:55 <nirik> sgallagh: ? 17:41:57 <sgallagh> s/package/arch/ 17:41:59 <sgallagh> Sorry 17:42:03 <jwb> oh 17:42:09 <dgilmore> sgallagh: yes 17:42:13 <jwb> we have a process for that 17:42:15 <t8m> sgallagh, I think it is implicit 17:42:19 <jwb> but yeah, kind of implied 17:42:22 <nirik> yeah. 17:42:41 <mitr> sgallagh: “by default”, though taking shortcuts by reusing stuff that already exists (like existing servers in existing racks that noone else needs) would I hope be permissible. 17:42:49 <nirik> I would also hope if we demoted say... i686... we would be clear what criteria it would need to be secondary/etc. 17:42:50 <jwb> wait, sorry. strike my process comment. i was thinking of something else 17:42:54 <jwb> still implied though 17:43:24 <jwb> nirik, if we do that i would hope we'd go a step further and line it up before we demoted 17:43:25 <dgilmore> nirik: I do think we need to look at a plan to demote i686 to secondary status 17:43:42 <jwb> nirik, lots of lead time, deprecate in release N, demote in release N+1 or N+2 17:43:50 <dgilmore> assuming that there is people wanting to keep 32 bit x86 around longer term 17:43:50 <nirik> sure. 17:44:01 <jwb> because just dropping it like we did ppc makes it 10x harder to bring back 17:44:04 <nirik> I'd be happy to see it go. ;) 17:44:20 * sgallagh is in the "burn it down and salt the earth" crowd, personally 17:44:28 <nirik> anyhow, next week chair? anyone? 17:44:35 <sgallagh> I'll take it. It's been a whie. 17:44:37 <sgallagh> *while 17:44:39 <mitr> dgilmore: I wonder. With all the talk about being a fractured platform that breaks apps, the 32-bit userspace (not booting in 32-bit) might be worth maintaining for a very long time. But that’s for some other time. 17:44:41 <jwb> (actually, ppc might have been doen that way and nobody cared enough to pick it up until after the fact. i can't remember) 17:44:48 <nirik> #info sgallagh to chair next week 17:44:50 <nirik> thanks sgallagh 17:45:10 <jwb> mitr, they already stopped supporting that 2 releases gao 17:45:12 <jwb> er, ago 17:45:21 <nirik> #topic Open Floor 17:45:25 <mitr> jwb: I was talking about 686 17:45:29 <jwb> mitr, ah! 17:45:33 <mitr> For open floor: Anything on #1334 (Zanata)? 17:45:57 <nirik> mitr: my understanding is that they wanted to keep discussing in ticket... since this is a bad time for them... 17:46:04 <t8m> I am OK with the transfer to Zanata for F22 17:46:43 <mitr> nirik: My guess is that bringing it up on the meeting might actually collect the +5 necessary way quicker than just reminding everyone in the ticket. 17:47:06 <sgallagh> This might be more a rel-eng question, but how are we feeling about Alpha? We identified several new blockers today at the review. Should we setting expectations? 17:47:15 <nirik> I'm happy to let translators do what they think is best... although I feel a bit uneasy that may not have been a full evaluation of alternatives... 17:47:29 <nirik> mitr: sure, true. 17:47:48 <dgilmore> nirik: same 17:48:14 <sgallagh> nirik: Sensible (with the obvious qualification of "within Fedora's Foundations and mission" 17:48:36 <mitr> nirik: More or less, yes. 17:48:43 <sgallagh> i.e. I don't love the idea of automating Google Translate or Bing! 17:48:51 <sgallagh> (not that this is on the table) 17:48:58 <dgilmore> sgallagh: Im confident we can build and deliver something, I honestly expect that Beta will look different to Alpha, as we will learn some lessons and have issues to fix along the way 17:49:15 <mitr> AFAICT our concern is primarily the scheduling, and even that only for the few dozen packages that are Fedora-native 17:49:18 <sgallagh> dgilmore: I meant more in terms of time-scale 17:49:34 <dgilmore> sgallagh: really depends on the bugs and how long they take to fix 17:49:40 * sgallagh nods 17:49:55 <dgilmore> sgallagh: the compose side being the big blocker is gone for now 17:49:59 <sgallagh> BTW, thanks and congratulations on getting out TC4 17:50:28 <nirik> http://pootle.translatehouse.org was mentioned... but anyhow, I am ok with them doing what they think is best. The history with transifex makes me sad to be moving things... oh well. 17:50:28 <dgilmore> still got some tweaking to go, but it's getting there 17:51:02 <dgilmore> nirik: I know that OLPC uses pootle 17:51:25 <t8m> it's slightly confusing talking about two topics at once :) 17:51:30 <nirik> zanata does have interested developers already working with the community. 17:51:34 <dgilmore> t8m: true 17:51:52 <mitr> proposal: FESCo is fine with https://fedoraproject.org/wiki/L10N_Move_To_Zanata ; please schedule the upstream project migration to happen after F21 final release is approved. 17:51:59 <nirik> so, any other votes on the 1334 ticket? or shall we vote in ticket/discuss more next week? 17:52:26 <t8m> mitr, +1 17:52:33 <sgallagh> mitr: +1 17:52:41 <nirik> mitr: +1 17:52:48 <thozza> mitr: +1 17:52:49 <kalev> mitr: +1 17:53:04 <dgilmore> +1 17:53:16 <nirik> #agreed FESCo is fine with https://fedoraproject.org/wiki/L10N_Move_To_Zanata ; please schedule the upstream project migration to happen after F21 final release is approved. (+7,0,0) 17:53:27 <nirik> any other open floor topics? 17:54:03 * thozza will be on vacation for next 2 weeks... so will not attend the next two meetings 17:54:19 <kalev> regarding possibly demoting i686, we could try and do it step by step 17:54:28 <kalev> like ship only x86_64 install images for F24 or whatever, but at the same time still build everything for i686 too to keep multilib support 17:54:37 <kalev> and then, in a later release (F25? or F26?) it would allow us to drop the i686 kernel and really force even the upgraders to x86_64 17:54:56 <jwb> we could do all kinds of alternatives too 17:55:11 <dgilmore> kalev: perhaps. we should talk to OLPC as thier x86 hardware is all 32 bit only 17:55:23 <dgilmore> so we should make sure that we continue to support them 17:55:39 <jwb> dgilmore, they don't use our kernel 17:55:39 <dgilmore> there is a ton of options for what we can do 17:55:40 <kalev> definitely -- also, if we keep building stuff but don't roll our own images, they'll still be able to ship their custom images 17:55:49 <dgilmore> jwb: not yet, but i have heard they plan to down the road 17:56:06 <jwb> i'd like to see an interim step where we only install the 64bit kernel on 64bit CPUs. userspace could still be 32-bit 17:56:13 <thozza> is there a way how to migrate actual i686 Fedora to x86_64? 17:56:14 <mitr> I think we will have to expect quite a few contributors interested in keeping i686 going, with varying / currently unknown ability to actually do it. 17:56:21 <jwb> thozza, yes. reinstall ;) 17:56:36 <thozza> jwb: that's what I was afraid of 17:56:42 <mitr> thozza: It would be highly desirable to build one, yes. 17:56:57 <jwb> mitr, i'm not sure about that 17:57:12 <dgilmore> jwb: that should be doable. just need to work with releng and anaconda teams to make it happen 17:57:21 <nirik> I would hope the number of people who install i686 fedora on x86_64 hardware is small,but I could be wrong. 17:57:27 <mitr> jwb: I think we could _survive_ the migration without it, but it would be painful for many people 17:57:54 <jwb> nirik, surprisingly not. lots of people love PAE for some unknown reason 17:57:57 <nirik> we can also look and see how well the centos 7 i386 effort goes. 17:58:16 <nirik> jwb: sad 17:58:22 <jwb> nirik, i would expect it to go much more poorly than a well planned fedora demotion 17:58:30 <jwb> because they literally have to bootstrap from nothing. 17:58:35 <nirik> true enough 17:59:13 <nirik> does anyone want to take on coming up with some proposals around i686 ? 17:59:37 <jwb> people hate me enough as it is. i'll be happy for someone else to lead there. maybe the server WG? 17:59:55 <nirik> or base... but sure. 17:59:59 * dgilmore needs to run and pick up daughter from school 18:00:05 * kalev needs to run too. 18:00:12 <nirik> anyhow, anything else for open floor? 18:00:38 <nirik> will close in a minute or so. 18:00:49 <sgallagh> Nothing from me 18:01:30 <nirik> #endmeeting