On Wed, Apr 18, 2012 at 06:18:34PM -0700, Brendan Conoboy wrote: > On 04/04/2012 03:26 PM, Matthew Garrett wrote: > >>Can we quantify what the overall experience is that must be > >>consistent? I understand Anaconda installations is considered a > >>part of this... except when it's not for EC2 images. What I'm > >>looking for is "These 10 things are partof the Fedora experience- > >>any PA needs to provide at least 7 of them" or something like that. > > > >The only differences between the Fedora experience on ARM and x86 should > >be those dictated by hardware. > > Just hardware, or hardware and software? Just hardware. The software should be equivalent between both. > Or hardware, software, and community? If hardware is capable of > providing a desktop experience, but only with proprietary drivers, > does that mean the arch isn't acceptable as PA? We still support unaccelerated video hardware. > What if some forms of the hardware are desktop capable, others are > not, but the community only has an interest in supporting headless > installations? Then it's not fit to be a primary architecture. > >>This makes sense, but what is adequate? Perhaps 1 distinct person > >>in each group saying "I will be responsible for $ARCH?" What if > >>only 1 person wants to be the secondary representative in both > >>groups? > > > >That's something that would have to be discussed with the infrastructure > >and release engineering teams. > > If that's the case please spell it out: > > SA must secure from the Fedora Infrastructure and Release > Engineering teams a statement that they are prepared to support the > SA as PA. It us up to these teams how to form that consensus and > provide an answer. The question should be formally posed to their > respective mailing lists unless they have an otherwise stated > policy. > > Or something like that. Seems reasonable. > >>This is overloading "support" so I'm having a little trouble > >>understanding the intention. Let's try a thought experiment that's > >>a little more generic than the above. I propose any given > >>architecture falls into at least 1 and possibly all 4 of the > >>following categories: > >> > >>1. Specs not suited to Fedora at all (too little RAM, no MMU, etc) > >>2. Can run Fedora, but Anaconda installation doesn't make sense for > >>technical reasons. > >>3. Can run Fedora, would even benefit by Anaconda installation, but > >>requires changes to Anaconda and/or other packages to work. > >>4. Can run Fedora and Anaconda supports it fine. > >> > >>I think what you're trying to express is that either 2 or 4 must be > >>true and that if 3 is true, 4 must also be true. Is that right? > > > >Yes, I think that's accurate. > > Okay- would you put that in the document? That's... what it already says? I'll attempt to clarify it. > >>>All supported platforms must have kernels built from the Fedora > >>>kernel SRPM and enabled by default in the spec file. Each kernel must > >>>be built in a timely manner for every SRPM upload. > >> > >>What exactly is timely? What margin is acceptable? Is this only > >>for kernel or does this apply to any package with a > >>much-longer-than-average build time? What would constitute being in > >>that class? Or should the class be critical-path packages? > >>Something else? > > > >The kernel's kind of a special case due to the relatively frequent > >security updates. The exact nature of what kind of speed is required > >would probably need to be discussed with the kernel team. > > I believe a subsequent discussion on the matter has yielded the > value of 4 hours. Can the guidelines include this, perhaps with the > caveat of "At the time this draft was approved, the agreed maximum > build time for a kernel was 4 hours." No, because it's the kind of thing that's going to be influenced by multiple factors. Each architecture seeking PA status should have this discussion with the kernel team. > >If architecture-specific issues get fixed in a timely way then the > >developer resources are sufficient. I don't think it's something that > >can be explicitly quantified. > > Okay, you're clearly writing that with a do everything to be PA > while SA, then you'll have proved yourself mindset. That's fine, > but it would help to spell this out. You might just as well say all > architecture-specific issues are fixed before promotion may be > granted. I'm not sure that's an achievable goal, frankly, but that > does seem to be what you're saying. Becoming a PA won't magically produce extra maintainers. It's still going to be up to the architecture maintainers to deal with ARM-specific bugs in packages, if the package maintainer isn't able to deal with them. So, yes, I think in this respect it's important for the SA to demonstrate that it's not going to hold up development once it becomes primary. > >>Is simulated hardware acceptable? Remote-X or VNC access? Physical > >>hardware? What happens when a new generation of hardware comes out? > >>What about architectures where there is no video at all? What about > >>architectures where some systems have video, others don't, but the > >>primary use case is systems without video? > > > >Whatever level of access is required to fix the bugs. The aim here is to > >deal with architecture-specific but otherwise generic issues - if X > >fails to work on a specific model then that's just a bug and it's not > >the end of the world, but if X fails to work on ARM at all then that's > >something that needs to be fixed. My experience of dealing with these > >things is that it's pretty difficult to fix most of these bugs remotely, > >so I'd probably expect that hardware be physically available to the > >people who need to fix the bugs. > > Would like to see clarification on whether using a simulator (with X > support) would meet this requirement. If not then the requirement > is essentially: Most packagers on the critical path must own one of > these SA-supported systems before it can be primary. A simulator might be sufficient in some circumstances - I'd really need to defer to people who do more work on graphics for that. Most crit-path packages could be handled fine in qemu, which is why the criterion mentions hardware-dependence. There's not a huge amount of userspace code that falls into that category. > >>>Excludearch may be used only to disable packages that are > >>>fundamentally architecture specific. > >> > >>Assuming we mean the package has architecture specific components > >>that either can not, or have not, been ported, agree. > > > >I'm not enthusiastic about excludearch being used simply because a > >component hasn't been ported, but I think that's probably a stronger > >position than we've traditionally had so I'm probably ok with it being > >used for that. > > Okay, please clarify in the document. Ok. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
