Glenn, 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? Thanks, John 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?) > > -- Glenn >
