On Tue, Mar 20, 2012 at 11:30 AM, Jon Masters <jcm@xxxxxxxxxx> wrote: > 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. What is the tracker bug? I'd like to take a peek. >> 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 -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
