Hi again, I want to thank you, and everyone else in FESCo for talking with us yesterday, and for looking over the proposal. Bear in mind, it's a work in progress. We intend to have broader conversations over the coming months and F18 is an optimistic goal. Nonetheless, I feel it is achievable (we've done many more disruptive things!) but we have also many points along the way at which we can back out, and remain SA. To address a few of these points...at least, I'll try :) First, just to repeat, we took the proposal to FESCo yesterday in the spirit of "early and often", not in the spirit of "final deliverable". Therefore, while it is true we've not yet reached out to everyone for input, that is because it is still a work in progress for us. We'll iterate based on feedback, and based upon yesterday and reaching out to other groups. On 03/20/2012 11:52 AM, Peter Jones wrote: > 1) mechanisms need to be in place to get package maintainers access to fix > arm-specific bugs in their packages So we have a tracker bug at the moment. Is that sufficient? If so, we obviously should make sure that it is included in the proposal docs that we have this in place and are using it. > 2) excludearch is not an option. This is fundamentally contrary to being > a primary arch. In fact this is one of the defining characteristics of > a secondary arch. Let's think about this some. ARM (32-bit) doesn't do Intel-style microcode, MCE, or many other things that x86 does. I don't think that means we should build packages that are x86-specific for ARM systems. We generally believe that we're starting from a point of good momentum, but there are some packages that won't ever be appropriate for ARM, and there are others where the FTBFS has been longstanding, or there are other (IMO valid) reasons why it might initially be Exclude. That doesn't mean that there would be many such cases. Nonetheless, I think it would be unreasonable to set the entry bar so high that there can be no things left to fix. That basically retains the x86 monopoly. > 3) arm must be integrated to the formal release criteria Agreed. We'll need to figure that out. > 4) when milestones occur, arm needs to be just as testible as other > primary architectures So we have a new hire (hi Paul) who is looking at autoqa, and we're going to pull together as much as we can here. It would help me to know (and we're reaching out to QE separately - per my other mail) what you would consider "testable" to mean, in terms of what you'd want to see. > 5) installation methods must be in place. I'm not saying it has to be > using the same model as x86, but when we get to beta, if it can't be > installed, it can't meet similar release criteria to existing or prior > primary arches. Where possible, we should be using anaconda for > installation, though I'd be open to looking at using it to build installed > images for machines with severe resource constraints. So we feel it more appropriate to use image creation tools at this point, for the 32-bit systems that we have in mind. There will be servers this year, but not yet, and they represent a small part of the overall value of ARM to Fedora. When you have systems that cost more than an order of magnitude less than their x86 brethren, that does mean there are some implementation differences. For one thing, the reason most of these boards are inexpensive is that they've done away with dedicated flash on-board for U-Boot, etc. Instead, the SoC (chip) contains enough minimal logic to load everything it needs for further initialization from an SD (typically) card. The normal model that has been established is that cards are provisioned separately and inserted into a board. Think of these as appliances, kinda. There are ARM netbooks, but they are rare. We'll get to Anaconda for some of the bigger stuff later, but for now, that seems less important than ensuring that we use standard Fedora tools to make the images. > 6) supported platforms must be fully integrated into building and > installation. If you need a special build procedure to make this happen > for kernel, we need to have rel-eng signing off saying they've approved > of whatever method that is, and QE signing off that they think it'll > result in a something they can claim is tested enough to release as a > primary arch. Fine. I think we got onto a tangent yesterday with the kernel. It's one part of the overall system. It's an important part, but it's just a part. What we are proposing is that we target a limited number of ARM kernel "variants" (subpackages) during a typical build - perhaps even only versatile - because this allows us to return a built kernel more quickly than building many variants. I had planned to take this to the kernel team, but let me just add a few points since it's raised here: 1). There are too many 32-bit ARM kernels. We know this. Work is going on in Linaro to address that. We will constrain ourselves to a small set of supportable targets and allow contributors to handle support for more exotic boards that few people have an interest in, much as anyone could build a non-PC x86 system and do some kind of non-Fedora for it. A large amount of "behind the scenes" work is currently ongoing to ensure that the same 32-bit mistakes do not happen with 64-bit. 2). There is no intention to use anything other than the official kernel package. The SPEC file can be modified (as it has) to build subpackages for different ARM targets. My suggestion was that by default we limit this to a small number, and we retain logic so that it is possible (through macros, koji flags, whatever) to build a kernel that targets more ARM platforms in some cases. We will discuss that separately with the kernel team, as I have said. 3). Kernel build time on our embedded targets is not great compared with x86. However, the ARM server hardware we will use in PA will have many times as much cache, memory, etc. and we believe will build the kernel much more quickly. For workflow, it is my opinion that folks care that ARM not stall issuing new builds or extracting others from the pipeline. For example, if you submit a kernel build and it includes x86 and arm subbuilds, the x86 subbuild won't stall waiting for arm, it will complete. The only thumb twiddling is waiting for the arm kernel to complete, which will be a bit longer, but we're also planning to have so many builder nodes that you won't be blocking for arm builds to begin. As I said, we'll discuss this with the kernel team. > 7) it can't be a serious maintenance burdon due to build related issues. > We need a couple of groups to sign off that builds are fast enough, not > just on a "full distro rebuild" (throughput) level, but also on a > "doesn't destroy my workflow due to waiting on it" (latency) level. Sure. Absolutely is a concern for us, as you can see from my other comments above about the kernel, for example, but not just that. Thanks, Jon. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
