On Fri, Oct 30, 2020 at 2:30 PM Garrett D'Amore via Python-Dev < python-dev@python.org> wrote:

I’m not on this list. But I have offered to help - if there are tasks that need to be done to help this I can help put the weight of a commercial entity behind it whether that involves assigning our developers to work on this, helping pay for external developers to do so, or assisting with access to machine resources.

For the record there are multiple illumos distributions and most are both free and run reasonably well in virtual machines. Claiming that developers don’t have access as a reason to discontinue the port is a bit disingenuous. Anyone can get access if they want and if they can figure out how to login and use Linux then this should be pretty close to trivial for them.

Thanks! It usually isn't just about access. This email thread and related tweets appear to have served their purpose: To drum up volunteers+resources from the otherwise potentially impacted communities. The valuable thing is developer time. Access: I took it upon myself to spin up some Solaris-derivative VMs for Python dev things in the (now distant) past. It wasn't a positive experience, I won't do it again. Bonus on top of that: Oracle, the owner of Solaris, is *still* actively attempting to destroy the entire software industry <https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc.>. Working on anything attempting to directly benefit them is a major ethical violation for me. Others make their own choices. I won't even spin up major BSD VMs anymore for a similar reason. It isn't a good positive use of my time, even despite having an enjoyable past with those OSes and knowing several past and present Free/Net/OpenBSD core devs. I look forward to new *Solaris buildbot(s) joining the fleet, -gps

On 10/30/2020 5:08 PM, Garrett D'Amore via Python-Dev wrote:

I’m not on this list. But I have offered to help - if there are tasks that need to be done to help this I can help put the weight of a commercial entity behind it whether that involves assigning our developers to work on this, helping pay for external developers to do so, or assisting with access to machine resources.

What’s more likely is that some group of developers aren’t interested in supporting stuff they don’t actively use. [snip] I think it is more of a matter of pride in putting out a quality product and not making claims that might be false. Anyway, here is what I posted on the issue. https://bugs.python.org/issue42173 """ Dear Solaris Python fans (about 20 so far here): Here is the situation. There are 1000s of open issues on this tracker and at least 100s of open cpython PRs, and only 20-30 core developers, mostly volunteers, actively (depending on definition) merging PRs and maybe another 10 triagers helping to manage issues.

You all can help on issues by checking whether reported bugs still exist with current Python (3.8+) on current 'Solaris' (which includes what?). Searching open issues for 'Solaris' in 'All text' just returned 114 hits. About half were last touched over two years ago, and sometimes the last touch was inconsequential (a version or nosy change). I suspect many of the 114 are obsolete. For example, the last comment, five years ago, on #1471934, says the problem was fixed in Solaris 11.2. Does this mean the issue should be closed? The bottleneck for merging PRs is reviewing PRs. We coredevs cannot do enough reviews ourselves. But any competent user can help. Reviewing has two components. First, does the patch fix the problem? Testing this requires a Github account and a local clone and ability to build a test binary. See devguide.python.org for more. Second, does the patch meet our standards of code quality. Solaris-specific patches likely change the C part of cpython, so C competence and understanding of PEP 7 is needed here. """ Of the 114 issues mentioned above, not all are Solaris specific, and at least one says not a problem on Solaris. Any at least some are obsolete. Anyway, 67 are marked as having a patch. Of those, about 25 have a github PR, the others should have an uploaded .patch or .diff that could be made into a PR. Slicing another way, 20 and 15 are marked as type 'behavior' and 'compile error'. A few errors are possible. Another 11 have no type selected. So I guess there might be say 30 bug issues that affect Solaris and that have a patch to review and improve. So one or more of your people could select issues of interest and help get a patch to where they think is it ready to merge. Then ask if some coredev that can do so will do a final review and possible merge. In message msg380008 yesterday, Victor listed steps toward a buildbot, starting with a census of failing tests to discover the current state of CPython 3.10 on Solaris. -- Terry Jan Reedy