12:14 p.m.
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
12:22 p.m.
On Thu, Jan 3, 2013 at 1:14 PM, Jared K. Smith <jsmith(a)fedoraproject.org>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
1:03 p.m.
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
1:43 p.m.
On Thu, Jan 3, 2013 at 2:03 PM, Peter Robinson <pbrobinson(a)gmail.com> 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
1:50 p.m.
On Thu, Jan 3, 2013 at 7:43 PM, Jared K. Smith <jsmith(a)fedoraproject.org> wrote:
On Thu, Jan 3, 2013 at 2:03 PM, Peter Robinson
<pbrobinson(a)gmail.com> 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
6:32 p.m.
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_Promot...
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. / blc(a)redhat.com
12:34 p.m.
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
11:46 p.m.
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. / blc(a)redhat.com
4156
days inactive
4168
days old
7 comments
5 participants
participants (5)
-
Brendan Conoboy -
Jared K. Smith -
Peter Robinson -
Tom Callaway -
Zach Oglesby