I seem to remember some kind of koji diff report that would come out periodically. Is there an automated run of this? I would love a dashboard or NxN matrix of diffs between all the arches. A timeseries would be perfect (to see the trends Matthew is referring to). Aha, found what I was thinking of: https://lists.fedoraproject.org/pipermail/arm/2013-February/005336.html Can this be rolled into automation in a more official way? Even something per-package like what Debian does is a start: https://packages.debian.org/wheezy/mlton-compiler vs. https://apps.fedoraproject.org/packages/mlton Thanks, Adam On Tue, Jun 10, 2014 at 5:20 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Tue, Jun 10, 2014 at 09:49:58PM +0100, Peter Robinson wrote: >> > What's depressing is the trend, not the absolute count. I'd expected it >> > to head rapidly towards zero after the first release, but instead it's >> > still growing. >> >> Is it? Where's your proof? From the patches and dealings with it >> personally that's not my understanding and if it is the case it's not >> due to the ARM team but because packagers aren't following the >> packaging process.... and in this case we actively fix them when we're >> made aware of the incident. > > In the past 6 months, 6 bugs added, 2 bugs closed - > https://bugzilla.redhat.com/show_activity.cgi?id=485251 . > >> > Anyone who has a usecase that relies on one of those packages will have >> > an inconsistent experience if they attempt to reproduce it on ARM. >> > That's harmful. It makes us look bad. It gives the appearance that we're >> > willing to release a worse product simply in order to claim ARM support. >> >> And if they engage with us about that experience we do our best to >> deal with them where possible. There's a few cases where I'm aware of >> that we don't package because the HW is actively not supported on ARM >> or similar style cases. In those cases I would argue that it's better >> not to build the packages as arguably no experience is better >> experience than a bad experience especially if there's potential of >> issues that offer a worse experience, hardware breakage or data >> corruption. The fact is that the x86 and ARM use cases don't match up >> 100% and I don't see the point in trying to glue those together 100% >> for the sake of a check box. > > Where there's reliance on specific hardware functionality that's absent > then yes, absolutely, there's no benefit in building the packages. > Figuring out how to communicate that to users isn't an entirely solved > problem, but with luck nobody's actually buying ARM hardware with > unrealistic expectations of its functionality. > > But I can't find any examples of those in the tracker. They all seem to > be cases where packages are either missing dependencies, take too long > to build or are just missing support. They're code. We can fix them. > >> > I don't think the current state of the ARM port is good enough. That's >> > not a reflection on the people involved. That's not a criticism of the >> > amount of effort that's been made. I just want to know how we can get >> > from where we currently are to where we want to be. >> >> Well why didn't you say that from the start rather than coming in and >> bullying the people actively involved and make them feel like the >> massive effort myself and many others have been putting in is useless >> and a waste of time. Don't be a Magpie Board Member and fly in and >> shit over everything and than fly awau with no concept of what's >> happening below. Every time you've had any attempt at opinion that's >> the way you've done it and all you do is get all our backs up and make >> the problem worse rather than better. > > I'm genuinely sorry if I gave the impression of bullying here. I want to > feel comfortable pointing at the ARM port as an equal to the x86_64 one. > I don't feel entirely comfortable doing so at the moment, and the > current process doesn't seem to be getting us to the point where I would > be. > >> > Individual package >> > maintainers seem happy to just add an ExcludeArch, maybe file a bug >> > against upstream and then forget about the issue. Given a lack of direct >> > incentive for them to care about ARM, that's not terribly surprising. >> > What can we do about that? Is the only realistic answer to find the >> > resources to have a team to hunt down and fix portability issues that >> > are sufficiently far from the core that the existing ARM community can't >> > justify the time? And if so, is there any way we can make that happen? >> >> I'm not sure I agree with your outline here, you've given no real >> concrete examples here. I agree there's no real incentive but there's >> over 15,000 source packages in Fedora and there's less than 100 (last >> time I looked, unfortunately there's no easy way off checking this >> without downloading the entire src.rpms or checking out all 15K git >> repos) or so excluded from ARM and the vast majority of those are due >> to HW support. There's some like D where upstream has yet to port the >> stack. I'm sure there's others I'm unaware of but it's not because of >> the ARM team but rather the packager following procedures or engaging >> us for assistance. > > The quantity of the archive that's built and working on ARM so far is a > testament to the amount of effort that the ARM community have put into > this port. The question is how to finish that. All I'm saying here is > that the current approach of filing bugs doesn't appear to be resulting > in people actually fixing their packages. It's unreasonable to expect > you to do all of it. So what do we do? > > -- > Matthew Garrett | mjg59@xxxxxxxxxxxxx > _______________________________________________ > arm mailing list > arm@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/arm _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
