On Thu, Mar 22, 2012 at 11:01:55AM -0400, Jon Masters wrote:
> I'm not sure building only the qemu kernel is a great way
> go either, both from a ARM _and_ kernel perspective. It might be better
> to build that + 1 board from each armv5tel and armv7hl.
That would be fine too. I mean, we could compromise and choose a set of
qemu+obvious board as the minimum and then turn on the rest at certain
points in the cycle. Whatever works for you guys.
What might be useful is documenting how you plan to monitor how many people
are actually using the various images, and at what point you decide
to cut off life support. If we're spending an hour building an image
that just a dozen people are downloading, it's not really a good use
This isn't an ARM specific thing btw, we'd *love* to kill off support
for < 686-PAE, but sadly there are more than a few dozen users there.
> Yes. However, waiting for a day for your build to complete only
> it be canceled because some ARM variant died is one of the larger
Absolutely. Clearly, a day is nuts. But it sounds like a few hours for
ARM isn't as big a deal. Would 2 or 4 hours be your upper limit? etc.?
4 hours would really be the absolute maximum. A security issue coming in on
a Friday afternoon doesn't mean someone has to give up their weekend
working on builds/updates. (Yes, this is Fedora, no guarantees blahblah,
but we try our best to turnaround CVEs asap).
Another reason is that for rawhide, we frequently get a build a day done.
(sometimes multiple). To catch the patches Linus has pushed during the day,
it's not uncommon for one of us to do a build at the end of the work day
to end up in the next days rawhide. If it takes too long, we miss the compose
> Can you elaborate on disruption? We already spend time mucking
> with ARM configs during rebase (not intelligently mind you), and I don't
> think we grumbled too much about it. Aside from more bugs, is there
> something else you were thinking?
Well, it's really whether you're ok with that kind of thing sometimes.
We can't promise to be perfect, and in fact we can promise crap like
that will come up...so it's really whether you can live with that.
It would be good to at least have people going over our guesses at config options etc.
Our educated guesses may not be the best choices, and right now they seem
to be sort of ignored..
$ git annotate config-arm-generic | grep FIXME
ae6da83b (Dave Jones 2011-12-30 22:23:07 -0500 200)# FIXME: Guesses, need checking
On the subject of configs, I'd really like to see arm taking advantage of
the config-generic infrastructure. Having to add options in multiple places
on a rebase sucks.
At that point, I'd like to review some of the config decisions arm has made
which differ from every other platform.