Feedback on secondary architecute promotion requirements draft

[Matthew Garrett]

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 at srcf.ucam.org