For the 2013-07-17 meeting as the Change Proposal was announced on devel-announce list on 2013-07-09.
https://lists.fedoraproject.org/pipermail/devel/2013-July/184962.html
I probably won't join meeting. I have few questions: * build time: will be the time of build lower with time or do we have a lot of builders? I was wondering how long can take rebuild of Fedora or rebuild of subset of packages for different features. LibreOffice will be building for hours, does someone look into this issues?
installation: would it be anaconda changes needed or do you still install without it?
release criteria for arm must be different if GNOME won't be default or if anaconda is not used. It's questionable if we can have different criteria for different primary architectures. I guess yes, if it don't slow down testing and release of new Fedora.
how long will take to improve graphical drivers? Could the situation change?
I'm slightly against arm as primary right now. FESCo should firstly decide if we can have primary architecture only as headless server, then my questions wouldn't matter.
For the record I'm aware of the statistic http://scotland.proximity.on.ca/~jon/koji.times.html Good work and thanks for that!
mmaslano had some questions above that I didn't see answered in the thread.
Today's FESCo resolution: Build ARM on primary infrastructure. Whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time (+5).
Keeping the ticket open to track ARM status and possibly making the criteria more precise.
Replying to [comment:1 mmaslano]:
We have a lot of builders. Currently there's 24 configured and that will be increased once we've freed up some from the SA koji instance. We have a total of 96 ARM nodes in PHX.
Anaconda is working as does kickstart installs and generating images using appliance-tools with a kickstart file. There are more improvements happening here.
I'm not sure gnome will be default but it will be there but the QA guys have already said there's room there as KDE is also in the release criteria. Anaconda can be used, we don't generate traditional .iso live images but we do have the equivalent pre generated images for all the SPINs and they're built in koji just like primary. Once we've moved the infra over they'll be built just like the nightlies for x86.
how long will take to improve graphical drivers? Could the situation change? I'm slightly against arm as primary right now. FESCo should firstly decide if we can have primary architecture only as headless server, then my questions wouldn't matter.
Well it's not only a headless server, all the other desktops work very well. The drivers are improving all the time and the difference to 12 or even 6 months ago is great. nVidia has opened up the information for their tegra GPUs and there's work there to produce an accelerated driver that should work with gnome-shell and there's a lot of other work going on across the board. As to how long it will take... it's hard to say exactly but there's rumours of some other news on the horizon so it might change sooner than later.
Sounds promising, thanks for your answers.
From the 2013-07-17 meeting:
AGREED: "build ARM on primary infrastructure. whether it is released as a primary Fedora 20 or as 'Fedora 20 for ARM' depends on how well it fulfills release criteria and functionality criteria closer to release time" (+5) (mitr, 19:24:46)
From my email conversation with feature owners:
Absolutely! I'll update the ticket.
At the moment we're primarily aligning builds to primary in preparation for enabling arm for the mass rebuild. We had a couple of issues that are mostly fixed (two outstanding are python3 and java but we're working with the devs to get them fixed).
Peter
remove from meetings for now.
As we're starting F20 alpha freeze, I wanted to raise a concern about working ARM hardware at the moment.
As I write this, the only hardware that is currently working for ARM is highbank (caldexa server hardware) and none of the other common ARM platforms are working (pandaboard, trimslice, beaglebone black). From what I understand, the ARM folks don't consider this to be a big problem and don't want to block alpha on any specific hw.
Is FESCo OK with the idea of doing a PA release with very limited HW support?
As I write this, the only hardware that is currently working for ARM is highbank (caldexa server hardware) and none of the other common ARM platforms are working (pandaboard, trimslice, beaglebone black). From what I understand, the ARM folks don't consider this to be a big problem and don't want to block alpha on any specific hw. Is FESCo OK with the idea of doing a PA release with very limited HW support?
From a discussion that was had with QA I believe (and I'm prepared to be corrected here) that QA didn't want explicit HW "support" as explicitly supported HW isn't the way that it's done in x86.
Calxeda and VExpress (qemu) works fine. The clarify the afore mentioned HW platforms: Pandaboard - issues in 3.11, I'm working with kyle to get it fixed but it's a problem upstream Trimslice - works fine except a PCI-e issue, kyle is investigating this Beagle xM - works fine BeagleBone* - issue upstream with MMC, we're working to fix this. BBBlack isn't currenntly supported upstream but this is something we plan to support as soon as possible but it's likely post alpha.
There are other platforms that are reported to work too.
we're also working to get the Utilite into a working state in time for final release.
Replying to [comment:13 pbrobinson]:
As I write this, the only hardware that is currently working for ARM is highbank (caldexa server hardware) and none of the other common ARM platforms are working (pandaboard, trimslice, beaglebone black). From what I understand, the ARM folks don't consider this to be a big problem and don't want to block alpha on any specific hw. Is FESCo OK with the idea of doing a PA release with very limited HW support? From a discussion that was had with QA I believe (and I'm prepared to be corrected here) that QA didn't want explicit HW "support" as explicitly supported HW isn't the way that it's done in x86.
My issue isn't with specific HW "support" - it's that we don't have any working common hardware at the moment (I'm not counting caldexa, those are expensive and not all that easily found). If there was one other platform we have access to that worked, I'd be less concerned.
Calxeda and VExpress (qemu) works fine. The clarify the afore mentioned HW platforms: Pandaboard - issues in 3.11, I'm working with kyle to get it fixed but it's a problem upstream Trimslice - works fine except a PCI-e issue, kyle is investigating this
From what I understand, this PCI-e issue is affecting network which I count as "not working yet"
Beagle xM - works fine BeagleBone* - issue upstream with MMC, we're working to fix this. BBBlack isn't currenntly supported upstream but this is something we plan to support as soon as possible but it's likely post alpha. There are other platforms that are reported to work too.
I guess this comes down to "what are we OK with for alpha if ARM is PA?" and I have concerns about the current state. If the networking issue on trimslice is fixed, or one of the omap boards is fixed - I'm not so concerned. I don't expect everything to be working before alpha but I do expect to have some platforms available for testing outside of qemu and expensive server boxes.
WandBoard devices should work, I've had confirmation of at least the Wanboard Quad. I'm working on both BBones and Panda as time permits as is kyle.
Trimslice - works fine except a PCI-e issue, kyle is investigating this From what I understand, this PCI-e issue is affecting network which I count as "not working yet"
Trimslice - works fine except a PCI-e issue, kyle is investigating this
The wifi should work as it USB attached and it'll work via a usb to ethernet adapter as well as the USB bus works just fine.
The BeagleBone (Black and White) are now both booting (issue with the MMC now fixed). I've not yet had time to do any other more extended testing but will confirm what the wider state of their status soon but that will give us a widely available cheap target for testing that QA already have.
3.11.0-3?
From 2013-09-13 FESCo meeting: * AGREED: Follow blocker process per Alpha release criteria for ARM platfom issues. ARM team and QA can renegotiate release criteria if needed. (+:8, -:0, 0:0) (notting, 18:25:40)
Ergo, removing meeting keyword.
We've gotten to the F20 release and arm is a primary arch. Closing ticket.
I'm reopening because I think there's some ambiguity about how we got from the 6-months-ago decision from the FESCo meeting ("follow blocker process for F20 alpha release") to "We've gotten to the F20 release and arm is a primary arch."
I'm not ''opposed'' to that resolution but I want to be a little more clear about how we got there. Did the negotiation with QA happen? Were the various concerns above addressed?
From the QA side, we essentially started out treating it as a primary arch 'provisionally'. As a few Alpha TCs went by, arm became a de facto primary arch from QA's perspective.
For the record, at this point, I'm +1 :)
My understanding is that we approved it unless there were significant issues at alpha (or later milestones) at which time we would revisit. Since there weren't any such major issues, the promotion just took place.
Replying to [comment:24 kevin]:
That's what I recall as well. From a developer/maintainer perspective, it was a primary arch the instant it was switched in koji. The only thing that would result in it being demoted would be a poor quality release. Since QA seems to have covered that, it is basically primary for all intents and purposes. Given the press around ARM and F20 and the fact that nobody was actively correcting their reports, calling it anything other than primary just seems silly.
That's similar to my recollection. To add to this it was left to the various teams to highlight any issues they thought would happen. The ARM people were already working closely with most teams long prior to the F-20 "approval for promotion to primary". We treated F-19 as if we were primary to ensure it was as smooth as possible for when ever we did get the green light. QA was already well aware of the issues and we'd worked with them for a few releases. We had a big QA meeting for ARM at Flock too with video and IRC involvement. There was a few minor things that needed to be addressed but most of the decision for promotion was discussed in the various FESCo meetings prior to the approval (will be in minutes/logs) and on the mailing lists (a number of long threads on devel going back to prior to F-18) where most of the detail was thrashed out.
The idea was make ARM conditionally primary architecture, unless there's reason not to - poor release quality, poor HW availability (see comment https://fedorahosted.org/fesco/ticket/1136#comment:13 - it was raised to FESCo pre-Alpha) but in the end we got all support needed from ARM team not to ask FESCo from stopping it being primary arch (blocker bug fixes, testing). So let's stand behind it, it was one of the top marketing selling points and it got nice coverage in the media.
Yes, I see no reason to make any changes here.
Log in to comment on this ticket.