Ticket #1136 (closed general: fixed)

Opened 9 months ago

Last modified 2 months ago

F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary

Reported by: jreznik Owned by:
Priority: major Keywords: meeting
Cc: ausil, pbrobinson, jdulaney Blocked By:
Blocking:

Description

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

Change History

comment:1 follow-up: ↓ 6 Changed 9 months ago by mmaslano

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.

comment:2 Changed 9 months ago by mmaslano

For the record I'm aware of the statistic http://scotland.proximity.on.ca/~jon/koji.times.html Good work and thanks for that!

comment:3 Changed 9 months ago by toshio

  • Cc pbrobinson added

mmaslano had some questions above that I didn't see answered in the thread.

comment:4 Changed 9 months ago by mitr

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.

comment:5 Changed 9 months ago by jdulaney

  • Cc jdulaney added

comment:6 in reply to: ↑ 1 Changed 9 months ago by pbrobinson

Replying to mmaslano:

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?

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.

  • installation: would it be anaconda changes needed or do you still install without it?

Anaconda is working as does kickstart installs and generating images using appliance-tools with a kickstart file. There are more improvements happening here.

  • 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.

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.

comment:7 Changed 9 months ago by mmaslano

Sounds promising, thanks for your answers.

comment:8 Changed 9 months ago by mattdm

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)

comment:9 Changed 9 months ago by mmaslano

From my email conversation with feature owners:

<cite>

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

</cite>

comment:10 Changed 9 months ago by mmaslano

  • Keywords meeting removed

comment:11 Changed 9 months ago by mmaslano

remove from meetings for now.

comment:12 follow-up: ↓ 13 Changed 8 months ago by tflink

  • Keywords meeting added

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?

comment:13 in reply to: ↑ 12 ; follow-up: ↓ 15 Changed 8 months ago by 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.

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.

comment:14 Changed 8 months ago by pbrobinson

we're also working to get the Utilite into a working state in time for final release.

comment:15 in reply to: ↑ 13 ; follow-ups: ↓ 16 ↓ 17 Changed 8 months ago by tflink

Replying to 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.

comment:16 in reply to: ↑ 15 Changed 8 months ago by pbrobinson

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.

comment:17 in reply to: ↑ 15 Changed 8 months ago by pbrobinson

  • 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"

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.

comment:18 Changed 8 months ago by pbrobinson

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.

comment:19 Changed 8 months ago by jdulaney

3.11.0-3?

comment:20 Changed 8 months ago by notting

  • Keywords meeting removed

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.

comment:21 Changed 4 months ago by toshio

  • Status changed from new to closed
  • Resolution set to fixed

We've gotten to the F20 release and arm is a primary arch. Closing ticket.

comment:22 Changed 2 months ago by mattdm

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Keywords meeting added
  • Type changed from zFeature to general

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?

comment:23 Changed 2 months ago by jdulaney

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 :)

comment:24 follow-ups: ↓ 25 ↓ 26 Changed 2 months ago by kevin

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.

comment:25 in reply to: ↑ 24 Changed 2 months ago by jwboyer

Replying to kevin:

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.

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.

comment:26 in reply to: ↑ 24 Changed 2 months ago by pbrobinson

Replying to kevin:

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.

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.

comment:27 Changed 2 months ago by jreznik

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.

comment:28 Changed 2 months ago by notting

Yes, I see no reason to make any changes here.

comment:29 Changed 2 months ago by tmraz

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.