>> mainline and you're getting depressed over exactly 24 of them? I'm not
>> sure how 24 packages is providing a inconsistent experience. In some
>> cases the maintainer of the package hasn't bothered to close the bug
>> when support was added, in some cases ARM was added incorrectly. For
>> example just before mass rebuild we added Ada support which closed out
>> around 2 dozen other packages we didn't build prior.
>
> 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.
>> Ultimately I fail to see how missing 20 odd packages out of 15,000 odd
>> fails to "provide a consistent experience across primary
>> architectures" so if there's something more specific and constructive
>> you'd like to provide it would be useful or is this just a random rant
>> because your bored?
>
> 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.
>> Ultimately we've been working hard to provide as consistent
>> environment on ARM as possible and improving all the time and all you
>> seem to do is randomly come in Magpie style and shit on something
>> without any other visible involvement in the ARM process or community
>> or any context and pick on something of random like a bully. If you've
>> got constructive criticism feel free to engage properly to assist us
>> in improving and coming up to your exacting standards but this means
>> of bullying tactics isn't the way to do it.
>
> 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.
> 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.
Peter
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm
No comments:
Post a Comment