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@srcf.ucam.org> 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@srcf.ucam.org
> _______________________________________________
> arm mailing list
> arm@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
No comments:
Post a Comment