On Thu, 2012-04-19 at 02:42 +0100, Matthew Garrett wrote: > > >>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. If the hardware never has a real framebuffer, like s390, then I wouldn't demand a simulator with a framebuffer. arm isn't like that, but arm's also weird in often not having PCI. I'd _prefer_ to have a simulator that had a GPU that resembles something people actually have, but even qemu-on-x86 fails that test (ha ha ha cirrus). I'd at least want something that presents a firmware interface that matches what you'd expect on real hardware (efifb or vesa on x86, offb on ppc, etc). It needn't attempt acceleration like vbox or qxl, since that's going to be per-device anyway. I'd obviously love to be more of a hardass about this, but I'm not going to make more demands of new arches than I'm making of the existing. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
