Hi Jared,

I'm sorry if this has been discussed in the last couple of meetings, as I wasn't able to make them (and haven't yet seen the logs of yesterday's meeting). To make a long story short, I'm looking for feedback on ways that we can make sure the Fedora ARM team continues to grow and scale and be productive as we inch closer to being a Primary Architecture in Fedora.

Nope, it hasn't, it's also something I think about quite a bit and never really get too far.

Let me use my own experience as an example here. I've been part of the ARM SIG since almost the beginning -- I've been in many (if not most) of the weekly meetings, I have two ARM devices up and running on my workbench, and I like to pretend I know at least enough to be dangerous. I try to follow the deep dark issues the core technical group is working on, but don't always understand what they're talking about. My question is this -- what can mere mortals like myself do (from either a technical or non-technical) standpoint to help keep things moving forward. There was a time when I was able to spend a bit of time every day helping out with pushing builds in koji and trying to track down packages that won't build correctly -- is that still needed?

The builds are mostly automated through koji-shadow, and most of the builds now mostly "just work" and those that break tend to be the harder ones that end up needing the maintainers to fix (eg eclipse). There's still some packages that need fixing and I try to file bugs where possible. I should really try and work out a list of "possibly easy fix" breakages which people can go through and poke at an either fix or file a bug so they can be tracked.

Are there "janitor level" tasks that folks can start on to get their feet wet and start contributing? Is there specific documentation that needs to be written? Tools that need to be tested? Scripts that need to be written?

I suspect there's work that can be done on the wiki, I've not looked at it closely in some time so I'm not sure but documentation is always in need of update.

I'm willing (as always) to put my time where my mouth is and help out -- please help guide me (and others in the group) in what you'd like us to do!

I think we're in a bit of a rut at the moment. A lot of the easy fix build issues are resolved and the builders mostly just sit their and do their job so a lot of the easy fix are done. We're getting prepared to push for primary (likely just v7) in the F-20 timeframe as things like enterprise HW and kernels etc are getting to the point we need and want so there will certainly be some work to update and expand the docs for primary promotion so that they're in good shape in preparation for that as we'd really want to put that to FESCo in the time around F-19 branching.

I think some of the best things that people with HW can do is to test all the various components of the HW and see what works and what doesn't. We tend to test core things like NIC/storage/usb/console and in the case OMAP the graphics but I've seen little or no testing of things like sounds, gpio, BT, wifi etc. A lot of devices have giro, gps, and a range of other sensors so it would be fabulous to be able to support these and have people confirm they work, in some case the HW will also need user space components as well, that might be testing that existing packages work with ARM HW, or in some cases the packaging of new bits. This is also true of testing new kernels against existing known good HW (have you tested the rawhide 3.7 kernel on the devices you have?).

The HW testing will be especially important with the 3.8+ kernels (when they land in rawhide) we'll start to be able to expand the amount of HW we support dramatically due to the maturing of things like DT and the unified kernel. With 3.8 we'll be adding a few more SoCs into the unified kernel which will likely bring us the ability to be able to support a whole new range of cheap HW like some of the imx6, AllWinner a1x (although may not be complete in 3.8) and the snowball device, as well as extra HW support for existing supported HW like the long awaited support for tegradrm.

It's also worth noting that while we have over 11K of the 12K packages in Fedora built on ARM it doesn't mean they necessarily work as expected. It's worth testing and playing with things that you would do on standard x86 systems too see if they work. For example I tested ipa-client today and registered it with a ipa server to ensure that that stack worked. A lot of the recent package fixes that I've personally pushed are due to packages, while building, not necessarily working as expected or in the most optimal way expected.

I hope this helps, is that the sort of thing you were looking for?

Peter