Date: Fri, 30 Oct 2009 13:11:28 -0700
From: John Fischer <John.Fischer at sun.com>
Subject: Re: 2009/579 [Python lxml]
This will be delivered through the SFW consolidation. The Install team
is unsure which consolidation they will end up in. ON makes the most
sense. With that all said, the Install team is the team delivering this
into the SFW consolidation.
Perhaps when the Install team uses the interface there should be a
contract established. Would that be acceptable?
I was hoping that the Python lxml library has had a history of
evolving without incompatible changes, so that Committed would be a
reasonable choice of stability in practice. (E.g., are the APIs
really likely to change incompatibly? If they have a moderately large
user base, that would seem to be an unlikely event.)
(I'm also not sure what it means to have an Uncommitted library
delivering implementations of Volatile APIs. In the interface table
below, does Uncommitted refer merely to the package name and library
location or does it apply to the library's contents as well?)
But if all parties accept these stability levels with their eyes open,
I won't stand in the way.
So +1, but I still hope to see the proposal modified to bump the
stability levels.
-- Glenn
Glenn Skinner wrote:
> Date: Fri, 30 Oct 2009 11:59:03 -0700
> From: John Fischer <John.Fischer at sun.com>
> Subject: Re: Python lxml [PSARC/2009/579 FastTrack timeout 10/30/2009]
> To: PSARC-ext at sun.com
>
> Anyone care to +1 this fast track?
>
> Thanks for the prod.
>
> ...
> >> The project will initially ship with Python 2.4 bindings as
> >> well as Python 2.6 bindings. Once the install code is
> >> ported to Python 2.6 then install will rely upon the Python
> >> 2.6 bindings. The port of install to Python 2.6 is
> >> underway.
> >>
> >> 2.1 Exported Interface table
> >> Interface Classification Comments
> >> ----------------------------------- ---------------
---------------
> >> SUNWpython-lxml Uncommitted SVr4 pkg
for
> >> Python 2.4
bits
> >> SUNWpython26-lxml Uncommitted SVr4 pkg
for
> >> Python 2.6
bits
> >> python2.[46]/vendor-packages/lxml Uncommitted Python
binding
> >> install
> >> location
> >> ElementTree API Volatile [4]
> >> lxml.etree API Volatile [5]
> >> lxml.objectify API Volatile [6]
> >>
> >> * Note: The Python 2.4 bindings are Obsolete Volatile to match
the
> >> Python 2.6 and 3.0 case (PSARC 2009/043)
>
> Given that install intends to use this library (and thus its API), are
> Uncommitted and Volatile suitable stability levels?
>
> (In particular, will they deliver into the same consolidation?)
