On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede <hdegoede(a)redhat.com> wrote:
On 12-07-17 15:18, Josh Boyer wrote:
> On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede <hdegoede(a)redhat.com>
>> On 11-07-17 22:57, Josh Boyer wrote:
>>> On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski
>>> <dominik(a)greysector.net> wrote:
>>>> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote:
>>>>> I ran into this unannounced change:
>>>> I noticed this is categorized as self-contained, which I think is
>>>> I also have hardware that would no longer run Fedora after such change
>>>> (a netbook with an older Intel Atom CPU which supports SSE2, but is
>>>> 32bit). Unless the change proponent can provide some numbers suggesting
>>>> that 32bit users are a tiny minority of our userbase, I'll probably
>>>> be against such change.
>>> Anyone with 32-bit hardware is going to be against this change. It is
>>> a known downside. It also doesn't change the fact that i686 kernels
>>> are in a zombie state, where the kernel team does not actively support
>>> them and the community has not significantly stepped up to do so.
>> I still have (some) 32 bit hardware in use and I must say that I was
>> not aware of this zombie state. i686 kernels have been working fine for
>> me otherwise I would have likely stepped up to fix things (or if that
>> was too much work replace my last 32bit hardware), but I may just have
>> been lucky and never hit a bad kernel.
>> If the kernel team wants some specific help with ia32 support then
>> 2 things need to happen:
>> 1) A clear request for help needs to be send
>> 2) What exactly they need help with needs to be clearly defined
Which is yet another generic, non specific call for help. Which
unsurprisingly (given its unspecificness) did probably not get
a lot of response.
What would be helpful is a concrete list of things people who
care about i686 can work about. For example an i686 kernel tracker
bug + link to that on the https://fedoraproject.org/wiki/Kernel
That's a great idea. Are you volunteering to triage all the bugs and
create it and maintain that list?
I believe that something among the lines of: "we need help, but
are not really specifying what, still please do something" is not
going to get you a lot of help.
OTOH "here is a prioritized list of TODO items, if all of the
high prio items have not been solved before $date, then we are
going to have to drop ia32 support from F28" OTOH will likely
be much more effective IMHO. This will cut 2 ways:
1) It will likely get the kernel team more help
2) If the kernel team does not get help, or not enough, then
you have a strong argument that not enough people care about
ia32 bit support and it should be dropped
I have no vested interest in the kernel team any longer other than
history and sympathy for the workload they face, but it is 100%
acceptable for a team with that much workload to simply say "we are
not prioritizing this anymore" irrespective of what other people want.
To be honest, they've done much more to keep it building and working
than I would have. So while you may want them to define concrete
actionable items, I don't find that acceptable. They don't do that
for arm, ppc64le, or s390x yet those continue to build and work just
fine. People that care about i686 should be able to step in and
define those themselves. If they can't then I'd suggest the kernel
team just ExcludeArch i686 at the next build break. At least that is
an immediate actionable item.