On Mon, 2009-01-26 at 12:28 +0000, John Levon wrote: > On Mon, Jan 26, 2009 at 06:05:42PM +1300, Laszlo (Laca) Peter wrote: > > > > > This project delivers Python 2.6 and 3.0 into Solaris. Python 2.4 > > > > and Python 2.5 are now Obsolete. > > > > > > This seems an awfully sudden jump from working Python to 'you need to > > > port all your code to Python 2.6'. I don't recall offhand how serious > > > the incompatibilities are between 2.6 and earlier? > > > > The reason why we'd like projects to move away from 2.4 is so that > > we only need to have 1 version of Python on the OpenSolaris LiveCD, > > where space is limited. Some parts of the next version of GNOME will > > need at least 2.5. We will move to 2.6, but we will also need to > > have 2.4 on the LiveCD until IPS moved to 2.6 too. > > Seems like a good reason to start the process for obsoleting 2.4 now, > and *possibly* 2.5. But I don't think you can reasonably immediately > obsolete 2.4 without any previous warning.
My understanding was that flagging an interface as Obsolete _is_ the warning. Maybe I'm misunderstanding something, but the Obsolete and EOF process[1] says: "The first step in removing something from the system is to conduct a project whose aim is to reclassify it as obsolete." It also seems to require a 1 year timeout from reclassifying before the interface can be removed. > BTW 'Obsolete' is a modifier not a classification, see the interface > taxonomy. Right, so the interface table should read Obsolete Uncommitted for those items. > Since 2.4/5 are uncommitted, this allows you in theory to remove them in > the next build. This can't be right. > > > > Projects delivering Python modules are required to deliver them > > > > for all non-Obsolete versions of Python that are shipped on the > > > > system. New projects do not have to deliver Python modules for > > > > Obsolete versions, but existing modules must be delivered for > > > > all versions. > > > > > > Surely 2.4/5 should be going through a longer period of obsolesence > > > rather than just disappearing at any point from now. There's a lot of > > > Python code out there. > > > > It's not going to disappear any time soon, in fact we have no plan to > > make it disappear. At the very least, it should remain in the IPS > > repository since, as you say, there's a lot of Python code out there. > > The reason for declaring it Obsolete is to signal that new projects > > should not target 2.4 or 2.5 and to ease the requirement of delivering > > all python modules for 3 different versions (and possibly multiplied > > by 2 ISA variants). > > I would have expected to see something like: > > - mark 2.4 as Obsolete Uncommitted, with some indication in the case about > following a notification period, instead of immediate removal > > I guess your comment above will do this Right. There is no plan to remove it in the foreseeable future, that's why there was no notification period, but I should have made that clear. > - keep 2.5 in its current state > - new code must deliver to 2.5 and 2.6, but not 2.4 > OR > - make 2.5 be like 2.4 > - new code must deliver to 2.6, but not 2.4 or 2.5 > > This would depend on if 2.6 is really incompatible. I couldn't find > any clear statement on incompatibilities, and if they're considered > bugs or not. Do we have an idea? There are some. I don't have a definitive list, but a few examples I know of: - the .pyc format changed - strings are not supported as Exceptions - some modules have been deprecated and produce warnings, e.g. posixfile, popen2, sha, md5 - C modules need to be recompiled due to ABI changes So, the changes are not huge, but apparently 2.6 makes the transition to 3.0 easier. > - code may deliver to 3.0 if upstream has a version > > As Rich Lowe pointed out, you're now requiring that any new Python > code deliver for both 2.6 and 3.0. Given that would require permanently > forking the upstream codebase, this seems rather onerous! Yes, Rich is right. I promised to clarify that paragraph. What you have above is correct, projects only have to deliver to 3.0 if an upstream version that supports 3.0 exists. They are not required to do the port from 2.x to 3.0. > Perhaps I'm really arguing that Python being Uncommitted no longer > reflects the reality of the situation. So, we have 3 "mostly compatible" versions (2.x) and an incompatible version (3.x). Given that new (incompatible) versions are introduced in parallel with the previous versions, they could be Committed. That said, we still need to pick one version that all core OpenSolaris apps use and using other versions should be discouraged. Laca
