Glenn, Thanks for the +1.
I understand the desire for a higher classification. I will monitor the community and respond appropriately when I see the interface evolution slowing down. I noticed that there were several deprecated interfaces between lxml 2.0 and lxml 2.1 as well as function name changes between major versions. Because of these facts I am not yet comfortable with declaring a higher commitment level. Again, I will monitor the community for the group and the ARC. You are correct that the Uncommitted interfaces refer to only the package names and directory locations. With that I am marking the case closed approved. Thanks, John Glenn Skinner wrote: > 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?) >
