On Wed, Jul 12, 2017 at 12:23 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > > On 12-07-17 16:33, Josh Boyer wrote: >> >> On Wed, Jul 12, 2017 at 10:14 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >> wrote: >>> >>> Hi, >>> >>> >>> On 12-07-17 15:18, Josh Boyer wrote: >>>> >>>> >>>> On Wed, Jul 12, 2017 at 9:09 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >>>> wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> On 11-07-17 22:57, Josh Boyer wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 11, 2017 at 4:41 PM, Dominik 'Rathann' Mierzejewski >>>>>> <dominik@xxxxxxxxxxxxxx> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tuesday, 11 July 2017 at 22:26, Florian Weimer wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I ran into this unannounced change: >>>>>>>> >>>>>>>> >>>>>>>> https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I noticed this is categorized as self-contained, which I think is >>>>>>> wrong. >>>>>>> >>>>>>> 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 >>>> >>>> >>>> >>>> >>>> https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html >>> >>> >>> >>> 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 >>> page. >> >> >> 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 we >>> 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. > > > I find this response not helpful at all, what I see happening here is: > > Person a: We need help > Person b: Ok what can I do > Person a: We need help figure it out yourself > Person b: Huh, so there is nothing to do. Ok then I guess I will go and do > something else. No, you're completely misconstruing the email thread I linked to. We said people interested in helping could do so, and gave a link to some bugs that could be looked at. But the crux of the original post wasn't a cry for help. It was a clarification of where the kernel team would be spending their time. So to phrase it in conversational form it's more like: Person a: We're going to be spending our time looking at x86_64 and fixing issues there. i686 isn't a priority for us. Person b: <silence> > Feel free to substitute me for person b because any desire I had > to make time to help with this just went out the window. OK. I'm not concerned about that at all. > More importantly I've the feeling that you can substitute a lot > of potential volunteers for person b in the above exchange. > > To me the we need help or we will just drop support mantra, > combined with not willing to put some effort into organizing > said help feels a lot like the we need help is just an excuse > to just drop ia32 support as that is what you really want > to do all along. Again, we didn't ask for help in that email thread. It clarified where the kernel team was going to be spending its time. i686 is not an itch the kernel team will be scratching and hasn't been for some time. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
