On Wed, Mar 21, 2012 at 1:04 PM, Josh Boyer <jwbo...@gmail.com> wrote: > On Wed, Mar 21, 2012 at 8:12 AM, Peter Robinson <pbrobin...@gmail.com> 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. >>> >>> >>> A tracker bug is certainly not sufficient. It would be for a SA, but not >>> PA. Typically our users have a PA at their disposal, or failing that have >>> ready access to a shared PA provided by the Fedora Project that they can log >>> into and do their testing. >> >> How was this handled in the case of PPC? My understanding is that due >> to legal reasons the Fedora Project never officially provided access >> to PPC machines. There were a number of machines that users could get >> access to that were provided by individuals but these were never >> officially provided by the Fedora project. > > That is correct. > >>> Without ARM systems available for all the releases our maintainers have to >>> support this is a non-starter. I will also note that having to resort to >>> using a remote system because the arch isn't generally locally at a >>> maintainer's disposal /is/ going to introduce a delay in getting bugs >>> resolved and builds out the door. If the arch was ubiquitous in a way that >>> lent itself to easy debugging and use that'd be a different matter, but I >>> just don't see it as being there right now. >> >> There's a number of cheap hardware becoming available such as the >> Raspberry Pi as well as development boards that are available for >> either purchase or people can apply to be part of a developer program >> to get either discount or free hardware. How was this supported with >> PPC? The PPC hardware was a lot more expensive (either Apple devices >> or IBM) than the readily available ARM devices. We can also put a >> means escalation in place too for those that don't want to purchase or >> can't get ready access to HW for testing. > > I think you're really asking the wrong question, or maybe taking the wrong > approach. There are a number of reasons PPC was _demoted_ to a secondary > arch, and this is one of them. Asking how it was done while PPC was a PA > is just spinning your wheels. It doesn't matter.
No, I was using it as a point and it's certainly not the approach I'm taking. >>>>> 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. >>> >>> >>> Perhaps Peter can clarify or soften this requirement a bit. EXCLUDEARCH as >>> a default action when a build fails on ARM is certainly not an option. What >>> would help your situation is generating a few lists of packages. One list >>> would be packages that you feel just don't make sense on ARM. Another list >>> would be the FTBFS you mention. These lists can be debated and decided upon >>> /before/ the migration to PA and the ExcludeArches can be in place before >>> the switch is pulled. >> >> There's a couple of different categories here. >> >> 1) x86 only hardware. There's things like dmidecode, cpuid, various >> ACPI, numa, EFI and other HW specific things like intel GPU drivers >> where it just doesn't make sense to build on ARM, just like it didn't >> make sense to build the various PPC utils etc on x86. In some cases it >> might be a short term exclusion as it's expected that the support will >> come to ARM, EFI is the classic case here. Others like intel GPUs >> never will. > > Yes. All good. > >> 2) packages that have x86 dependent code. spice comes into this >> category and I've discovered a few others. This would need work from >> someone, either the Fedora maintainer or upstream. > > Er... I think you forgot "or the Fedora ARM team". Seriously, if you are > counting on getting the Fedora package maintainer to fix something like > that, you are going to be disappointed. You cannot force them to fix it > and ExcludeArch is often the resolution until the arch team comes along > and fixes it. Nope, not forgotten, the "Fedora ARM team" component was a given, but ultimately there has to be some form of involvement from both levels of maintainers because otherwise everytime a patch doesn't rebase they'll just comment it out and move on, I'm fully aware of the requirements of the ARM team..... just look at my name though out all build reports for this year to see that. >> Ultimately as the person that has done 98% of the builds and lead the >> building of rawhide the vast majority of the packages where we've >> added ExcludeArch are where they are x86 or PPC only for a reason, in >> fact in a lot of cases I've removed excludes (icedtea-web and a number >> of other packages) to ensure we run on ARM. Where it's FTBFS on ARM >> there's been bug reports and dialog with maintainers to get the issues >> fixed. Most maintainers have actively assisted with this, some have >> stated they don't care, in those cases we generally go and fix the >> issues ourselves. In quite a few of the cases with build issues it's >> actually people doing weird shit in spec files that cause the problem. > > This is exactly what I meant above. You've done great work, but what you > describe is simply going to continue whether ARM is primary or secondary. > I just don't want people to think the effort you've put in thus far is > somehow going to magically decrease if ARM is promoted. Nope, we're not that naive but my point is that we're not just asking for it to be promoted to Primary Arch because we'd like to pat ourself on the back for all our efforts, we believe (and if you look at the hype in the industry in general) that ARM is going to be a large part of the market moving forward and we believe that ARM being well supported in Fedora is represented in part of our core values of the project. Ultimately it will mean a lot of lower cost hardware being available for users all over the world and for them to be able to run Fedora easily on those devices I believe would be an awesome thing. And yes, while it's certainly possible for it to happen as a secondary arch there's a whole lot of issues surrounding that like the expectation that a few people fix every problem and there's a little QA effort when people can be bothered and various developers will fix things when they can be bothered and it ultimately makes people think "no one in Fedora cares about ARM I'll just go an run some other distro where they do care and it is supported". I'm fully aware that Primary Arch isn't the perfect panacea and that once we're there the ARM team can't go and sit of the beach and do nothing but it does spread the load, automate a lot of things because it's part of core infra and processes and it then allows the ARM team to concentrate on fixing corner case packages, working with various components of the project, optimising the way things are done for ARM, working with upstreams for HW etc and generally making ARM even better rather than constantly chasing our tail trying to keep up with basic things as building packages, running infrastructure, composing the repos, dealing with branching and tags and targets in koji and all those other things. Those advantages of being a primary arch can't be under valued. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
