On Wed, Mar 21, 2012 at 2:52 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > 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. Exactly! Ultimately what we need is FESCo to document what are the requirements of being promoted to a primary architecture and then it's the ARM SIGs job of ensuring they adhere to the requirements, provide viable workable alternatives that are acceptable to FESCo, or provide proof that the requirement will be met within an agreed time frame. Ultimately the ARM SIG knew there would be issues and discussions, ultimately there has never really been an architecture promoted to primary in the current project guidelines since core/extras were merged so there's no criteria for promotion and it was always envisioned that the creation of generic promotion criteria would be part of the requirements of the eventual promotion of ARM. Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
