>>> >> >> 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. _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
