Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/09/2013 10:34 AM, Tom Callaway wrote: On 01/08/2013 07:32 PM, Brendan Conoboy wrote: 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? Is there a current status on this? This was a very popular item in my recent Reddit "What should Fedora do in 2013" post. Assume you mean the Pi/armv6hl question- expect this will be a topic discussed at FUDCon extensively. We have the future of armv[5678] to discuss! -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/08/2013 07:32 PM, Brendan Conoboy wrote: > 2. New architecture bootstrap support. We'll be in a position where > many hands make light work in aarch64 soon. Likewise, Seneca is > proceeding with armv6hl, perhaps they could use a hand? Is there a current status on this? This was a very popular item in my recent Reddit "What should Fedora do in 2013" post. ~tom == Fedora Project ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On 01/03/2013 10:14 AM, Jared K. Smith wrote: 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? Thanks for starting this thread! There are basically 3 things that we really need help with (off the top of my head): 1. Democratizing ARM support. Right now we have a relatively small set of supported targets in the ocean of ARM devices. The raspberry pi is one example where non-core contributors are making this unsupported platform viable, if only in remix format. The chromebook is the next stellar example. And the allwinner-a10 devices. We need to make the Fedora ARM tent bigger, if it means remixes due to upstream issues. As kernels are unified and drivers are sent upstream the effort that goes into these remixes can then be made mainstream in Fedora. 2. New architecture bootstrap support. We'll be in a position where many hands make light work in aarch64 soon. Likewise, Seneca is proceeding with armv6hl, perhaps they could use a hand? 3. Anything that advances ARM's promotion to Primary Architecture status. As a reminder, the FESCo guidance for this is at: https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements Item #10 is is great need of attention: We really need to merge as much as possible with the main Fedora wiki pages. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On Thu, Jan 3, 2013 at 7:43 PM, Jared K. Smith wrote: > On Thu, Jan 3, 2013 at 2:03 PM, Peter Robinson wrote: >> I hope this helps, is that the sort of thing you were looking for? > > Yeah, those are exactly the sorts of things I was looking for. In > particular, though, how do we get from "there are probably some things > on the wiki that need to be fixed" to a list of items that people can > take and run with? Not sure, pwhalen might be able to give some direction here or just role your sleeves up. Sorry I can't be helpful here as I barely have the time to consult it. > Also, do we have a defined mechanism to report packages that aren't > working as expected? Bugzilla? Wiki page? Shouting in the IRC > channel? Bugzilla with "ARMTracker" as the blocker is the primary means of tracking so things don't get lost and are tracked. Ultimately it's the package maintainers job to fix problems with the package but often we fix them. A lot of maintainers are quite responsive, others not so much. Patches with fixes are obviously a help, feel free to ping me if there's any you have issues with. Peter ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On Thu, Jan 3, 2013 at 2:03 PM, Peter Robinson wrote: > I hope this helps, is that the sort of thing you were looking for? Yeah, those are exactly the sorts of things I was looking for. In particular, though, how do we get from "there are probably some things on the wiki that need to be fixed" to a list of items that people can take and run with? Also, do we have a defined mechanism to report packages that aren't working as expected? Bugzilla? Wiki page? Shouting in the IRC channel? -- Jared Smith ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
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 ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] How to increase contributions from new members of the SIG?
On Thu, Jan 3, 2013 at 1:14 PM, Jared K. Smith wrote: > 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. > > 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? > > 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'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! > > -- > Jared Smith > Jared, +1 to your comments. I am extremely interested in helping however possible, but its can be difficult jumping on to a moving train. As I mentioned in the meeting yesterday, I may be easier to wait until FUDCon, but if there is low hanging fruit that new people can work on putting it on the wiki would be helpful. Zach ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
