1:02 p.m.
===================================
#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-...
.
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