Possible platforms to drop in 2.6
I originally posted this list to python-3000 since I figured we could be more aggressive with Py3K, but Guido said I should move it over here and just be aggressive in 2.6. So, here are the platforms I figured we should drop: * AtheOS * BeOS * FreeBSD 2 (maybe more?) * IRIX * NeXT * OS/2 * UnixWare I had SunoS 5 but Ronald Oussoren said that is actually Solaris through version 9, so I took that off. Several people have questioned AtheOS, but considering the site for the OS has not been updated since 2002 and it was a niche OS to begin with I doubt we really need the support. There is a fork of AtheOS called Syllable (http://www.syllable.org/) that is still being developed, but someone from that group should probably step forward and offer to help maintain the code if we are to keep it. Same goes with BeOS and Zeta (http://www.zeta-os.com/cms/news.php; there is a drop-down in the right-hand nav column to change the language to English for us non-German speakers). And I listed FreeBSD 2 as a drop since FreeBSD 3 seemed to have been released in 1999. But if most users have upgraded by now (release 6 is the most current) then we could consider dropping 3 as well. -Brett
Brett> So, here are the platforms I figured we should drop: ... Brett> * OS/2 I'm pretty sure Andrew MacIntyre is still maintaining the OS/2+EMX port: http://members.pcug.org.au/~andymac/python.html Skip
skip@pobox.com wrote:
Brett> So, here are the platforms I figured we should drop:
... Brett> * OS/2
I'm pretty sure Andrew MacIntyre is still maintaining the OS/2+EMX port:
I am, although I haven't managed a binary release of 2.5 yet (should be in a few days). If its just the os2vacpp subdirectory in PC/ that is being discussed, that could go for 2.6. It will be a fair amount of work to disentangle the defines used for the 2 ports - a fair bit of the platform specific code is shared, but with compiler related differences. I would suggest more trouble than its worth for 2.6, but I could work on it. Of course, if the project management decide that even the EMX support should be removed from the official tree - so be it; I will just have to maintain the port outside the official tree. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia
On 12/23/06, Andrew MacIntyre
Of course, if the project management decide that even the EMX support should be removed from the official tree - so be it; I will just have to maintain the port outside the official tree.
I don't think that's the objective. In general we don't mind if a resonable amount of platform-specific stuff sprinkled over the source tree, *as long as there is someone to maintain it*. Such code tends to break each time a major feature is added or modified, which is pretty much every release. If no-one is there to repair these, the platform code becomes useless, and *then* it becomes a matter of deciding to clean up unneeded hacks, to simplify future maintenance. We want to keep a reasonable balance where the code is reasonably clean and doesn't contain pockets of dead code that nobody understands, but if someone is actively maintaining a port we'd like to support them by minimizing the effort it takes for them to port each new Python version. It seems that you're on the ball, so we can keep your changes. We would appreciate it if you could point out things you no longer need (I understand the os2vacpp directory might be one of these?). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sunday 24 December 2006 00:19, Andrew MacIntyre wrote:
Of course, if the project management decide that even the EMX support should be removed from the official tree - so be it; I will just have to maintain the port outside the official tree.
I feel that so long as there's an active maintainer for a port, it can and should stay. It's the older systems where we have no maintainer and no way to check if it's still working that are the problem.
Brett Cannon schrieb:
I originally posted this list to python-3000 since I figured we could be more aggressive with Py3K, but Guido said I should move it over here and just be aggressive in 2.6.
Please follow PEP 11 in doing so. This means you cannot remove the code in Python 2.6, only break the build with an error message. Actual removal would be deferred to 2.7.
So, here are the platforms I figured we should drop:
* AtheOS * BeOS
In both cases, the last maintainer should be contacted before the platform is unsupported.
I had SunoS 5 but Ronald Oussoren said that is actually Solaris through version 9, so I took that off.
It's actually *all* Solaris versions (up to 11). Dropping support for 5.6 (Solaris 2.6) and earlier may be an option; we have some special-cased code for 5.6.
Several people have questioned AtheOS, but considering the site for the OS has not been updated since 2002 and it was a niche OS to begin with I doubt we really need the support.
IMO, that should really depend on active maintenance. Somebody should confirm that Python 2.5 still compiles out of the box on that system, and, if not, volunteer to fix it. If nobody does, we can remove the code in 2.7.
And I listed FreeBSD 2 as a drop since FreeBSD 3 seemed to have been released in 1999. But if most users have upgraded by now (release 6 is the most current) then we could consider dropping 3 as well.
This really should use the PEP 11 procedure: let configure fail (early) on the system, and then remove support if nobody complains (in 2.7 and 3k). Regards, Martin
On 12/29/06, "Martin v. Löwis"
Brett Cannon schrieb:
I originally posted this list to python-3000 since I figured we could be more aggressive with Py3K, but Guido said I should move it over here and just be aggressive in 2.6.
Please follow PEP 11 in doing so. This means you cannot remove the code in Python 2.6, only break the build with an error message. Actual removal would be deferred to 2.7.
I wasn't planning on skipping the procedures in PEP 11. I just wanted to get the list of possible platforms to eliminate out there for people to comment on.
So, here are the platforms I figured we should drop:
* AtheOS * BeOS
In both cases, the last maintainer should be contacted before the platform is unsupported.
I guess I can go off the emails listed in README and Misc/BeOS-NOTES, although I would hope that any maintainer would watch python-dev in some fashion. Is there an official list of maintainers? If not perhaps there should be a PEP listing who maintains what platforms.
I had SunoS 5 but Ronald Oussoren said that is actually Solaris
through version 9, so I took that off.
It's actually *all* Solaris versions (up to 11). Dropping support for 5.6 (Solaris 2.6) and earlier may be an option; we have some special-cased code for 5.6.
OK. I don't have a Solaris box so someone else might need to help with that.
Several people have questioned AtheOS, but considering the site for
the OS has not been updated since 2002 and it was a niche OS to begin with I doubt we really need the support.
IMO, that should really depend on active maintenance. Somebody should confirm that Python 2.5 still compiles out of the box on that system, and, if not, volunteer to fix it. If nobody does, we can remove the code in 2.7.
Yep. Guess that goes along with contacting the maintainers.
And I listed FreeBSD 2 as a drop since FreeBSD 3 seemed to have been
released in 1999. But if most users have upgraded by now (release 6 is the most current) then we could consider dropping 3 as well.
This really should use the PEP 11 procedure: let configure fail (early) on the system, and then remove support if nobody complains (in 2.7 and 3k).
Sounds reasonable. Hopefully it would catch people early in the alpha stage to deal with this. -Brett
Brett Cannon schrieb:
> * AtheOS > * BeOS
In both cases, the last maintainer should be contacted before the platform is unsupported.
I guess I can go off the emails listed in README and Misc/BeOS-NOTES, although I would hope that any maintainer would watch python-dev in some fashion. Is there an official list of maintainers?
Not that I know of. The AtheOS port was contributed through patch #488073, by Octavian Cerna (tavyc). It seems that the primary contributor for the BeOS port was Chris Herborth (chrish@pobox.com). Regards, Martin
participants (6)
-
"Martin v. Löwis" -
Andrew MacIntyre -
Anthony Baxter -
Brett Cannon -
Guido van Rossum -
skip＠pobox.com