On Tue, Apr 19, 2016 at 10:17 AM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >>>> >> >> I would like us to demote them to secondary. >>>> >> > >>>> >> > Why? We've already decided to drop. I'm not opposed, just curious why. >>>> >> > IIRC we were hitting a major problem with kernel compat as well? >>>> >> >>>> >> Pinging on this - I thought we'd reached a decision and wanted to >>>> >> publicize that sooner than later. >>>> >> >>>> >> If there's a reason to prefer move to secondary, let's discuss. >>>> >> >>>> >> Best, >>>> >> >>>> >> jzb >>>> > >>>> > I prefer to move it to secondary because people could be relying on it >>>> > still, it gives us a way to move forward and not be blocked on 32 bit >>>> > x86. If it does not work then it will not get shipped. Just dropping them >>>> > on the floor does not give as smooth a transition, nor does it give >>>> > people that want it still the chance to pick it up and continue to carry >>>> > it forward. >>>> >>>> Is the context Cloud, or in general? I think going from primary for >>>> all products to totally dropping it is a problem, even if install >>>> media is non-blocking. I have no stake in i686 at all, and I think >>>> Cloud and Server are less affected by totally dropping i686 than >>>> Workstation; but I think quitting i686 cold turkey needs >>>> reconsideration. >>>> >>>> Anyway I think no one has done anything wrong here, but the warnings >>>> of the kernel team were maybe considered something like, "oh, we'll >>>> get by one more release or two by the skin of our teeth before it >>>> blows up" and yet it just turned out that it's blowing up already. >> >> Sort of, yes. >> >>>> If the idea is we should block on i686 in general for upgrading, I'd >>>> agree, even though it's a pain. >>>> >>>> For Cloud, maybe the way forward at worst is to support Cloud Atomic. >>>> And the images are i686 only? Of course that assumes any problems with >>>> binutil and kernel, or whatever else comes up, is sanely fixable with >>>> a best effort. >> >> s/best/any. >> >>> My stance is that it hold true for all products, spins etc. I think we should >>> just make i686 a secondary arch completely in f25, in order to do it and keep >>> i686 multilib we need to redefine secondary arches. >> >> I'd be agreeable to this. In a related vein, I plan on drafting a >> Change to drop one of the flavors of i686 kernel anyway (likely the >> non-PAE kernel). For something we don't expend time on and isn't a >> focus, building two variants just so we can keep really old hardware >> around is kind of silly. If it moves to a secondary arch, they >> secondary arch team can deal with it. > > Define "secondary arch team" as I don't technically deal with the > kernel as part of the "secondary arch team" I deal with it for ARM as > my own interest, I help others (Power64/s390x) when it's just pushing > minor changes. Your examples matches my expectations. To expand it formally, "the group of people that step up to maintain the architecture out of their own interest." Ideally we'd have that group lined up before demotion, or i686 will go the way of sparc and ia64. PowerPC is the only architecture we've ever demoted, and there were people interested in plugging along with it as a secondary but initially it wasn't enough. Even it had to play catchup with a larger investment of people and machines. Machines shouldn't be an issue for i686 but we do need the people. josh _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
