On Mon, Jan 28, 2013 at 08:06:50AM -0800, Garrett D'Amore wrote: > SPARC is on the brink.
Not really. As a colleague put it, it's on the brink like the Prussian Empire is on the brink. Or I could use a Weekend at Bernie's reference. You get the idea. > So, if we don't have these resources, and nobody is able to provide > them, then I believe we don't have the resources to keep the SPARC > port healthy, and I don't think we should continue to try. In such a > case, I'll recommend that we consider SPARC a secondary port, and not > consider its functionality in deciding whether to integrate new > changes or not. (That said, I think we'll always be happy to accept > fixes for SPARC from volunteers who submit them with documentation > demonstrating that they have tested such fixes, but I imagine that > SPARC support will quickly degenerate if we stop requiring SPARC > functionality to work during the RTI process.) I'd prefer that we rip it out. Someone who later comes along and is serious about solving the problems you describe can reintegrate it by merging forward a snapshot from before the removal. Linux has a lot of half-broken "second class" ports sitting around, including for SPARC. It's not a model that works well; the various broken ports invite a lot of questions that no one can answer, and keeping up with the generic changes is a full-time job for one person. "Core" changes often break these second-class ports in ways that the single maintainer doesn't notice or will struggle to fix. Once a port has rotted, it's almost impossible to recover it to a working state anyway; having it in the gate the whole time makes no difference. Most of the time, if the second-class port is at all healthy, there will be a large set of pending changes that are under test or controversial or both, so that anyone who wants to actually use the second-class port can't use the official sources anyway. Worst of all, having examples around that are incorrect or no longer work is confusing to engineers working in other areas. Given that we have source control, keeping it around serves only to tantalise people who'd like to use it and, perhaps, confuse engineers working in other areas. The Linux SPARC world was, and I'm sure still is, full of stale FAQs listing what worked at one time, and mailing lists that rarely see traffic except the plaintive pleadings of would-be users. We can't afford that kind of distraction; we should make clear that we're focusing our efforts on an architecture that has a future, and invest 100% of our energy in that. Unfortunately, that architecture isn't SPARC. > in an open forum. And if a solution can't be found here, then it will > be obvious to everyone, and hopefully nobody will think worse of us if > we then decide to reduce our commitment to what will at that point be > obviously an unsupportable platform. Sadly, that's not the case. There will always be a small number of people who, for nostalgia or other reasons, are unable to let these things go. They lack the time and/or ability to fix the problems themselves, but will bargain and stall endlessly to keep "their platform" alive as they go through the various stages of grieving. I ought to know; I was one of them 10 years ago when the SPARCv8 Linux port was on the ropes. Don't enable that behaviour. If there's no clear commitment, with a timeline, to provide all of the things you described and to assist other engineers with SPARC-related problems so that it remains a first-class citizen, we need to remove the port in its entirety, and we need to do so as soon as possible. It's over, and it's been over for a long, long time. ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
