Peter Jones (pjones@xxxxxxxxxx) said: > In yesterday's FESCo meeting I told you I'd make a list of specific issues > I have with the current proposal for ARM as a primary archictecture. There > are some places where I think the current proposal fails to deal with some > necessary aspects of becoming a primary architecture, and some places where > I don't think the approach is quite right. So without further ado: > > 1) mechanisms need to be in place to get package maintainers access to fix > arm-specific bugs in their packages > 2) excludearch is not an option. This is fundamentally contrary to being > a primary arch. In fact this is one of the defining characteristics of > a secondary arch. > 3) arm must be integrated to the formal release criteria > 4) when milestones occur, arm needs to be just as testible as other > primary architectures > 5) installation methods must be in place. I'm not saying it has to be > using the same model as x86, but when we get to beta, if it can't be > installed, it can't meet similar release criteria to existing or prior > primary arches. Where possible, we should be using anaconda for > installation, though I'd be open to looking at using it to build installed > images for machines with severe resource constraints. > 6) supported platforms must be fully integrated into building and > installation. If you need a special build procedure to make this happen > for kernel, we need to have rel-eng signing off saying they've approved > of whatever method that is, and QE signing off that they think it'll > result in a something they can claim is tested enough to release as a > primary arch. > 7) it can't be a serious maintenance burdon due to build related issues. > We need a couple of groups to sign off that builds are fast enough, not > just on a "full distro rebuild" (throughput) level, but also on a > "doesn't destroy my workflow due to waiting on it" (latency) level. So, the thing I'm seeing over and over in the discussion (well, aside from Kevin), is these list of requirements that must be in place. However, none of these requirements require being a primary arch to do. In essence, if ARM is a primary arch in practice, then it should be able to become one in designation. Stating at an organization level "ARM is a primary arch pending on meeting criteria A, B, and C" seems backwards. We should continue on threads like this figuring out what makes a primary arch viable, and then table the discussion of whether ARM should be primary until it meets these viability standards. Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
