#830 define requirements for secondary arch promotion
Closed None Opened 12 years ago by rbergero.

For 2012-03-20 Open Floor and/or 2012-03-27 FESCo meeting.


http://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers (nirik, 18:45:42)
AGREED: ask qa, rel-eng, kernel and infra teams to provide feedback on the proposal. Ask fesco members to come up with critera that they would want to add and revisit next week. (+8,-:0,0:0) (limburgher, 19:09:50)

To start this off, two suggestions:
* Access to some ARM machines available to developers for debugging (would be a blocker for making one or both archs primary, not to starting the process)
* "Resolving" the installation difference - not necessarily by using Anaconda, but by figuring out how to minimize the differences between the installation paths to the satisfaction of $relevant_parties (which is rel-eng, QE, probably Anaconda developers [at least to the extent that nothing important has been left out in the ARM process], perhaps even documentation folks)

"While there are no commercially available enterprise ARM servers today, both Calxeda and Marvell will enable OEMs to provide Enterprise grade ARM servers in time."
* Could you be more specific about the time? I guess we need it to add them right now for F-18.

"If builder capacity proves insufficient, add more systems and repeat. Do we have finances or builds which can be added?"
* Do we have another hw, which can be added?

  • Do we have time statistics of previous rebuild of whole Fedora? What will be the sufficient result? 5% longer time of rebuild (more, less)?
  • Ensure that the kernel team has the man power to support ARM. Do they?
  • Work with anaconda team to develop ARM support. Does it mean that from the start we will support ARM builds but not the boot?
  • List of FTBFS packages. I'd like to see how many packages can't be build now and which one.

Replying to [comment:4 mmaslano]:

To answer some of these:

  • Do we have time statistics of previous rebuild of whole Fedora? What will be the sufficient result? 5% longer time of rebuild (more, less)?

Not at the moment, the production hardware will be a lot fast than what we have now. The biggest limiter at the moment is the amount of RAM for large packages so things swap a lot. The production HW will have 4Gb. Also we've been fixing a lot of broken upstream packages.

  • Ensure that the kernel team has the man power to support ARM. Do they?
  • Work with anaconda team to develop ARM support. Does it mean that from the start we will support ARM builds but not the boot?

In the short term we're looking at tools like livecd-creator to be able to create SD cards for devices like the Raspberry Pi and the various development boards. The first commercial servers are likely to have uEFI and will in all likely hood be workable with the current anaconda/kickstart means with little to no modification.

  • List of FTBFS packages. I'd like to see how many packages can't be build now and which one.

There are very few that are FTBFS that aren't already FTBFS in Mainline Fedora as per rel-eng's script from the mass rebuild http://ausil.fedorapeople.org/f17-failures.html

Of the rest we're working to get the last of the issues closed out. Of the total packages in F-17 of 11501 (according to koji) we have built over 10K unique source packages leaving a difference of around 1143. Of those 460 odd are FTBFS on F-17 mainline post gcc 4.7.0 mass rebuilt. The rest are a combination of the following:
- Will build but various minor failures that block on either dep broken on mainline or need minor adjustments for ARM. We're actively working on fixing those. Upstream maintainers should be working to fix the mainline FTBFS anyway
- Are part of the java stack, and we're activity working with the java team to close those issues out
- Are platform/HW specific and not relevant to ARM. eg numa, various virt bioses, ACPI, and other related
- Have issues building on one or both of the supported ARM architectures. The main one here is the mono stack and it's a known issue with upstream on hardfp
- Upstream either doesn't support or hasn't tested with ARM, most of these we're working with upstream to get fixes.

So with that we've less than 500 packages to go before we've built all we can. There's not a large delta of unsupported packages. Most are esoteric packages that haven't seen releases for a number of years to support random hardware or programming languages.

FESCo (2012-03-26)

agreed mjg59 will prepare wiki at the end of a week with list of requirements from devel list (+9,-0)

Discussion is postponed for the next week.

http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29

Today's FESCo meeting agreed to wait a week for more discussion on list, then vote on critera draft.

Accepted at 2012/04/23 fesco meeting

Would like a bit of clarification as the ticket summary was changed - when this was "accepted" at the fesco meeting, I'm not sure what was approved. Was it:

  • The actual documentation of Secondary Architecture Promotion Requirements

OR

(Or both?)

My concerns are that:
Secondary Architecture Promotion Requirements isn't a feature page, per se, so that doesn't address the approval of the Feature Page itself. (Or disapprove of it, for that matter.)
The FedoraARM feature page doesn't reference the Secondary Arch Promotion Reqs. page - and hasn't been updated to reflect anything relating to the Secondary Arch Promotion Reqs. page. It hasn't been touched since late March, and I would expect that if we had to go and make documentation relating to architecture requirements, that the feature page should address whether or not it is making progress in meeting those specific requirements.
* More generally, the Secondary Arch Promo Requirements page isn't linked to from anywhere on the wiki - it is a friend-less page with no referrers. I would expect that if this is a specific list of requirements, that we should have a page somewhere that is perhaps process-related or FAQ related (How does Fedora promote secondary architectures to Primary? or even under "What architectures are currently supported" somewhere, this would be useful to link to.)

In the meantime: I bumped the Feature Page back to FeaturePageIncomplete, and it of course can be moved forward if this was an approval by FESCo for it as an F18 feature, but I personally would at least like to see a checklist in the feature page showing progress on the specific requirements outlined in the arch promotion wiki page.

Sorry to post questions so long after, just trying to vaguely keep up with old job here at 3am :)

As an FYI this can be discussed at the next meeting, or if someone has concrete answers prior to that, that works as well. Up to you good folks!

I think it is pretty clear. The feature was rejected or rather not even voted about as it was clearly not ready to be approved. What was approved was the Secondary Architecture Promotion Requirements document.

Per FESCo meeting on Jun 25, the summary by Tomas is correct.

Login to comment on this ticket.

Metadata