Tuesday, June 10, 2014

Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective

On Tue, Jun 10, 2014 at 10: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 .

If you're going on just the bug tracker possibly but there's a lot of
stuff we fix and enhance that doesn't even make the that tracker, the
Ada stuff I mentioned earlier is but one example. Rightly or wrongly
it's not the canonical source of information. For example if I
discover an exclude arch I'll generally just go and fix it rather than
spending the time to open a bug, fix it myself and then close it
myself. Just go and read the rawhide reports. If that's what you want
us to do to give a warm fuzzy feeling of progress.... I don't see it
as a time effective agile way of necessarily dealing with it. Feel
free to suggest alternatives :-)

>> > 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.

Are you offering to do so? For example some time ago I approached one
of the root maintainers (comes out of CERN I believe) and they said
they didn't see the point nor have the time to maintain anything other
than x86 at this time. Should we fork it and support it just to say
we're "feature complete with x86" just because it's code? Well maybe,
but I'm not sure in that case it would add value to the distro for the
expenditure of time and we've had exactly zero enquires about it (and
it's 3 dependencies in the tracker). In the case of Hadoop there might
possibly be value (and in later releases the issues might even have
been fixed) but again we've had no queries and so we've focused on
things people want. In the case of Ada we had some requests for
support since F-20 was released so we've added that for F-21.

>> > 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.

Well you need to engage with us better. Every time you make an
appearance it appears to us all it's just to bully us. People
genuinely shudder when your nick appears on on the channel and I've
had 3 people thank me for replying so they don't have to.

So moving on from that.... why don't you feel comfortable pointing to
the ARM port? I'm aware we're still not perfect but it was always
going to be a road to improvement.

We're supporting massively more hardware now than we were at F-20
release time and the types of HW are getting better with the likes of
the Tegra K1 supporting full desktop equivalent graphics and we might
even have the support for that upstream in time for F-21 release, the
open graphics drivers are improving that they might be usable in that
timeframe too. Those were problems that were well known when we went
to primary and the path is basically what was agreed and mapped out in
that regards.

In terms of the general userspace I'm not aware of anywhere we
massively differ in feature set of packages or features within those
packages. Any time someone finds an area where we differ we fix up.
ExcludeArch packages are the easy ones to find, it's almost impossible
to find internal package ifarch issues for features without a manual
grep or similar of all .spec files and we fix when we find, if you've
got suggestions to improve how we deal with those I'm open to
suggestions rather than pure criticism but again this isn't the ARM
team actively trying to sweep problems under the carpet.

You also completely fail to recognise the positives we've contributed
but it doesn't actually seem you care about that anyway.

>> > 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?

I'm not sure but then I don't see you've actually contributed anything
to improving it either as yet, I'd love to hear of some positive
suggestions as I suspect it would also help the other non x86 non
mainline arches too.

I'd also love to hear of your suggestions of how we might encourage
more contributors to ARM. We know we have a lot of consumers of Fedora
ARM (I know of at least one installation of 100K devices) but they
don't necessarily contribute (apparently they had no issues for their
use case when I spoke with them about it) and while we have HW vendors
that actively test their HW and occasionally pop up here and there
they only care about their bits. We've tried HW giveaways but in most
cases people grab and run. So it varies. Thoughts and suggestions
welcome :-)

arm mailing list

No comments:

Post a Comment