libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
Hi James, Please check my in line comments below. cheers, Simon James Carlson wrote: > Simon Sun writes: > >> By default, the port 5060 is for SIP use. If two instances of one SIP >> proxy were started up, the latter one should fail since the default port >> has been occupied by the first instance. Same thing will happen to the >> two different proxies. It has nothing do with the library underneath. >> For this case, we just want to put back the library into SFW gate at >> this moment. >> > > I'm aware of what you're asking. I'm not sure what users will be told > through the documentation. > > >>> (I'm guessing the answers are that things may break, and, since it's >>> just an "option," we don't really care. Is that right?) >>> >>> >> It's incorrect. We do care the user's feeling. >> >> Actually there's no dependency between libsip and libosip2. All the >> interfaces and implementation are quite different from each other. There >> is almost certainly no sane reason to use both at once since it will >> definitely increase the complexity of the program. >> > > I'm not asking about what someone may do intentionally, but rather > what may *happen*. Accidentally having incompatible libraries loaded > at the same time is unfortunately quite common -- it happens because > libraries themselves have dependencies, as do plug-in modules. > > I looked at the source code for both, and it appears there's no > symbol overlap, so the chance of failure seems pretty low. > > >>> The short answer is that OpenSolaris is supposed to be a coherent >>> system, not just a random assemblage of parts. >>> >>> >>> >> Yes, absolutely. Since we've provided SIP support in Solaris, by adding >> another one which is more commonly used by OpenSource community, we can >> attract more user who is based on oSIP to Solars and lose nothing. Later >> on, we can port other application based on oSIP on other platform into >> Solaris. >> > > The policy I cited from PSARC 2009/147 said that the preferred > implementation needs to be pointed out to users so that when there are > duplicates, users know what they're getting. > > Please indicate which one of these two will be "preferred" and what > the documentation will say. > I'd express it explicitly in man page of libopsip2 like this: Solaris provides another library named libsip for SIP development purpose. We'd suggest you to consider using it instead. Please check the man page libsip(3LIB) for more info and refer to the developer guide at http://docs.sun.com/app/docs/doc/820-0643. > In particular: when future projects come to the ARC and propose to be > dependent on libosip2, should we tell them that they need to use > libsip instead? > Since I'm not quite clear the criterion of ARC, my suggestion is like this. If it's an existing application and depends on libosip2, no need to let he/she change to libsip since it means the code should be rewritten from the beginning. If not and it's a brand new project for SIP, ARC can ask them to use libsip. > >> It's similar to the libusb. Even through in Solaris we provide the >> USBA, we still put back libusb into Solaris to provide the end user >> another choice. >> > > I don't think this situation is similar at all. USBA provides kernel > interfaces to allow you to write a native driver for a USB device. > libusb(3LIB) provides a way to write a user-space driver for USB. > > In contrast, what we're talking about are two user-space libraries > with substantially the same functionality and just different names. > Thanks for making it clear. The point is we do provide a way for user to develop their application before libusb is put back. Then we put back libusb to provide another way. > Let's stick to SIP. Analogies like this to other cases tend to break > down in the details. > > >>> Or just architectural confusion. It's unclear which we get. >>> >>> >> They are two different implementations which are compliant with the RFC >> 3261. The user can choose the one he/she is more familiar with. >> > > That part is not true, and that's the problem I'm trying to get at. > > The idea of having a coherent system architecture is immiscible with > the notion of allowing users to pick and choose random internal > components to construct the system. We don't allow (for instance) > users to pick and choose between Sun's libc and GNU's glibc. It's not > that users don't want that kind of choice -- undoubtedly some do want > it -- we don't do it because allowing this sort of choice for > developers would lead to chaos for end users. The two libraries are > not just plug-in replacements for each other. > > Allowing users to pick and choose among foundational libraries such as > SIP is similarly suspicious. It causes at _best_ a fork in the road, > where some common features and bug fixes are available with some > applications but not with others, and all
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
Jim Walker writes: > James Carlson wrote: > > I urge the project team to consider bringing in at least one > > application that makes use of this library. Libraries without > > consumers are, in my opinion, just baggage. And in this case, given > > that the library also represents functional duplication, it doesn't > > provide much of an offsetting gain. > > > > We are looking into this already. > > I plan to submit the libexosip2 case after this one which is > required by many of the osip2 apps. We already went through that ... libexosip2 isn't an application, either. I'm suggesting that having a library as the top level deliverable isn't necessarily an interesting thing. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
logilab-astng [LSARC/2009/299 FastTrack timeout 05/18/2009]
After seeing the feedback on logilab-common, I will retarget logilab-astng to python 2.6 James Walker wrote on 05/12/09 00:27: > I'm sponsoring this familiarity case for Bobbie Long. The requested > release binding is minor. The man page and pydoc has been posted in the > materials directory. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: >logilab-astng > 1.2. Name of Document Author/Supplier: >Author: Bobbie Long > 1.3 Date of This Document: > 11 May, 2009 > 4. Technical Description > > Summary > === > logilab-astng[1] - Python Abstract Syntax Tree New Generation > > The aim of this module is to provide a common base representation > of python source code for project such as pychecker, pyreverse, > pylint, etc. > > logilab-astng 0.19.0 will be integratedinto the SFW consolidation > as part of this proposal, and will be installed as SUNWlogilab-astng. > > This project requests a minor release binding. > > Dependencies > > > SUNWPython > SUNWgnome-libs > SUNWgnome-python-libs > SUNWlogilab-common > > Interfaces > == > > Exported Interfaces Classification Comment > --- -- --- > SUNWlogilab-common Uncommitted Package > > /usr/lib/python2.4/vendor-packages/logilab/astng > Uncommitted Python Library > > Imported Interfaces Classification Comment > --- -- --- > SUNWPython VolatilePython interpreter, library > SUNWgnome-libs VolatileGNOME platform libraries > SUNWgnome-python-libs VolatilePython GNOME libraries > SUNWlogilab-common Uncommitted Common Python Libraries > > Reference Documents > === >[1] http://http://www.logilab.org/856 > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open >
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
James Carlson wrote: > Jim Walker writes: >> James Carlson wrote: >>> I urge the project team to consider bringing in at least one >>> application that makes use of this library. Libraries without >>> consumers are, in my opinion, just baggage. And in this case, given >>> that the library also represents functional duplication, it doesn't >>> provide much of an offsetting gain. >>> >> We are looking into this already. >> >> I plan to submit the libexosip2 case after this one which is >> required by many of the osip2 apps. > > We already went through that ... libexosip2 isn't an application, > either. I'm suggesting that having a library as the top level > deliverable isn't necessarily an interesting thing. I understand. We should have a candidate osip2 / exosip2 app soon. The initial app that was driving this case got lost somewhere? I'm still searching the email ;) Maybe these were on the FOSS 500 list. The libraries themselves seemed useful enough to warrant porting on their own. But it is better let the consumer apps drive things more. Cheers, Jim
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
James Carlson wrote: > >>> Are these being delivered by this or by some other project? And do >>> any of them work with the existing libsip? >>> >> These application will not be delivered by this case and I'm not sure if >> someone is working on porting them. None of them works with libsip. > > I urge the project team to consider bringing in at least one > application that makes use of this library. Libraries without > consumers are, in my opinion, just baggage. And in this case, given > that the library also represents functional duplication, it doesn't > provide much of an offsetting gain. > We are looking into this already. I plan to submit the libexosip2 case after this one which is required by many of the osip2 apps. Cheers, Jim
jar file man pages - was Re: trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
For LSARC, PSARC and the opinion writer(s) to consider Michael Kearney wrote: > 1. Lloyd, I like the idea of your annotation but have a couple of > concerns. > - Would teams be expected to update third party, open source jar > files with the annotation? > - Would the ARC provide the common @Taxonomy annotation Java code? I have concerns too. In general, we will not be able to change FOSS code upstream like this. We normally try to do as little modification as possible (ie. just enough to get it to run well on Solaris/OpenSolaris). This is another reason why short man pages are being tacked on. Is it possible to tack on a page to the javadoc? I don't want to see big javadoc patches in the SFW consolidation that document detailed taxonomy information that we have to carry forever because they will never be accepted into the upstream community. Why would a FOSS project creating jar files even care about our taxonomy rules? > 2. What if the man page simple documented the stability at the > granularity of the jar file and > nothing else. Perhaps the man page could generically reference the Javadoc? Not every jar file in /usr/share/lib/java has a man page, but that is the current practice, for the ones that do: $ man asm $ man mvel $ man janino $ man jettison $ man joda-time $ man jaxen-core $ man junit $ man ant (needs a more direct reference to javadoc) ... As I see it, having jar file man pages... 1. Provides users stability and availability (taxonomy) information about jar file packages on Solaris/OpenSolaris not available anywhere else. 2. Is pretty painless for project teams to produce and support. 3. Man pages do no harm, and I think users are already getting use to having them. Some information is better than no information. 4. Until there is a better way, man pages should be required for any new jar file submissions into Solaris/OpenSolaris. I thought this was already true. 5. Man pages are used by most Solaris/OpenSolaris packages. 6. I appreciate where Java developers are coming from, but "not standard practice for Java developers to look for man pages" alone, doesn't seem enough reason to stop man pages being delivered with jar file packages. We can't control how jar files are delivered or documented on windows or other environments, but we can on Solaris/OpenSolaris. BTW. ccing Norm (sfw c-team lead) since one of the requirements to integrate into sfw is a man page. Cheers, Jim
pywbem Ver 0.7 [LSARC/2009/258 FastTrack timeout 05/05/2009]
It's Ok. I will re-add the 3.0 version to the prototype_com Best Regards, ~Vivek R. Titarmare -Original Message- From: Danek Duvall [mailto:danek.duv...@sun.com] Sent: Wednesday, May 13, 2009 1:51 AM To: Vivek Titarmare Cc: 'Margot Miller'; LSARC-ext at sun.com Subject: Re: pywbem Ver 0.7 [LSARC/2009/258 FastTrack timeout 05/05/2009] On Tue, May 12, 2009 at 06:22:32AM -0700, Danek Duvall wrote: > On Tue, May 12, 2009 at 06:40:42PM +0530, Vivek Titarmare wrote: > > > I have updated the prototype_com file to just have Python version 2.6 in > > it. Below are the contains of the file. > > Looks fine to me. Actually, I was wrong when I said before that we didn't have 3.0; I'm not sure why I forgot about that. The prototype file you sent out with the 3.0 bits in it looked fine to me, once that's taken into account. Sorry for the confusion. Danek
LSARC/2009/250 - Firefox 3.0.x on Solaris 10
All, Actually, I have set the timer for Friday, May 15th, 2009, COB PST. Thanks, John John Fischer wrote: > All, > > Attached please find the updated proposal. I have reset the timer for > Wednesday May 20th, 2009. > > Thanks, > > John > > John Fischer wrote: >> All, >> >> I am putting this case into need spec status to allow the project team >> to produce a new specification that addresses the sharing of the Gnome >> libraries and installation locations. Once this is done I will restart >> the timer appropriately. >> >> Thanks, >> >> John >> >> Abhijit Nath wrote: >>> Alan/John, >>> Yes, it is a mistake. We'll shift all the private libraries/ Firefox >>> 3.0.x libraries in "/opt/firefox3". >>> You are also correct about the LD_LIBRARY_PATH. We'll modify the one >>> pager and incorporate LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64. >>> >>> Some other frameworks' up-prive (eg GStreamer) also need upgraded >>> gnome libraries( Refer Brian's mail). So we are in a process to check >>> the feasibility of keeping all the upgraded libraires in a common >>> place. We'll revert back asap. >>> >>> Thanks, >>> Abhijit >>> >>> On 04/22/09 04:40, John Fischer wrote: Alan, I totally missed the /opt/firefox and /opt/sfw issue. Thanks for catching that one. I'll let the project team address these issues. Thanks, John Alan Coopersmith wrote: > John Fischer wrote: >> This project proposes to back port Firefox 3.0.x from Nevada to a >> Solaris 10 Update release which is a Patch release of Solaris. > > Is it integrating into the update release or shipping as a separate > web download running on top of the update release? (/opt would be > wrong for the integrated case, right for the unbundled case). > > Is this intended to replace or supplement Firefox 2.x? > > The one-pager references both /opt/firefox3 & /opt/sfw/lib/firefox/ > - can > we assume /opt/firefox3 is correct since /opt/sfw is reserved for the > Solaris Companion CD? > >> All the plugins are spawned by firefox-bin. So, LD_LIBRARY_PATH >> environment variable will be set to /opt/sfw/lib in run-mozilla.sh > > This also seems incorrect - should this refer to the /opt/firefox3/lib > directory or are you importing/depending on libraries from the > Companion CD? > > (Also, in the unavoidable cases in which you must use > LD_LIBRARY_PATH-type > variables, you should always use LD_LIBRARY_PATH_32 or > LD_LIBRARY_PATH_64 > to avoid breaking programs of the other wordsize.) > > Are the library upgrades incompatible? Is there no way they can be > shipped as updates to the existing public libraries in /usr/lib ? > > For the brand new libraries, like cairo & dbus, is there any > architectural > reason they must be private, or is this just a resource issue > around supporting > them? > >>> >> ___ >> opensolaris-arc mailing list >> opensolaris-arc at opensolaris.org
libosip2 [LSARC/2009/277 FastTrack timeout 05/10/2009]
Simon Sun writes: > > Please indicate which one of these two will be "preferred" and what > > the documentation will say. > > > I'd express it explicitly in man page of libopsip2 like this: > > Solaris provides another library named libsip for SIP development > purpose. We'd suggest you to consider using it instead. Please check > the man page libsip(3LIB) for more info and refer to the developer guide > at http://docs.sun.com/app/docs/doc/820-0643. That seems reasonable; thanks. > > In particular: when future projects come to the ARC and propose to be > > dependent on libosip2, should we tell them that they need to use > > libsip instead? > > > Since I'm not quite clear the criterion of ARC, my suggestion is like > this. If it's an existing application and depends on libosip2, no need > to let he/she change to libsip since it means the code should be > rewritten from the beginning. If not and it's a brand new project for > SIP, ARC can ask them to use libsip. OK. That's the bit of policy information I was looking for. > > Are these being delivered by this or by some other project? And do > > any of them work with the existing libsip? > > > These application will not be delivered by this case and I'm not sure if > someone is working on porting them. None of them works with libsip. I urge the project team to consider bringing in at least one application that makes use of this library. Libraries without consumers are, in my opinion, just baggage. And in this case, given that the library also represents functional duplication, it doesn't provide much of an offsetting gain. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
trove-2.0.4 [LSARC/2009/262 FastTrack timeout 05/05/2009]
Instead of doing this via email, let's put this on the agenda for next week. At that time we can decide whether the below: Do not ship man pages with jar files should be a TCR, TCA, or Advice. That is the only outstanding issue on this case. Then, if everyone is ready, we can then vote on the entire case. Thanks, Margot Margot Miller wrote: > The case hasn't been denied; it's been derailed so an opinion can be > written and it will be clear if precedence has been set or not with > this case. > > From the LSARC meeting today, it seemed like the majority of > the committee thought it was fine for the project team and other > teams to ship a man page. I don't think that is the right way > to go, in that some jar files will have man pages, some won't > and Java developers probably won't look for a man page > anyway. > > I think Jim identified correctly a real problem - how do > we communicate the interface classification of a jar file to the > end user. I think we need a comprehensive and > consistent solution. And the javadocs proposal has a lot of > merit to it. > We are voting on whether the project team should be allowed > to ship the man page. (I thought the majority wanted that > but need to take an explicit vote) > > So if after the vote, I am in the minority, than the case is approved > and I write a section stating the minority opinion. If after the vote, > I am in the majority, then the case is approved, the team doesn't > ship a man page, and the minority can write their section of > the opinion if they chose. > > Margot > > > Mark Martin wrote: >> >> I'm presuming you're voting against this case as spec'd, with the >> offered opinion, correct? The project team hasn't been given a >> chance to make any advised or required modifications, so it seems a >> bit imprudent to deny a case in that manner. >> The intent here is that the man page inclusion precedent will be set >> here and now, right? If the vote sustains for approval with a man >> page, then there's no need to bring another case forth, right? Seems >> like Jim's gap would be addressed in that case. Or should the >> "optionally" token in the opinion text be taken as a failure to cover >> the gap? >> >> On the topic, though, I think Jim brings a very good point -- how >> does the project team communicate the expected stability? Lloyd >> brings an interesting solution with the use of Java Attributes as >> documentation decoration, although I have a few issues with it on >> technical grounds. For those not on the call, I see the problem as >> this: >> >> At some point, Sun must have established the precedent and the >> _expectation_ that stability levels of most types of interfaces were >> to be expressed to consumers of those interfaces in the man pages. >> I'm sorry I can't quote chapter and verse. This is, as far as I'm >> aware, a communication norm that I don't see in other systems, Sun >> originated or otherwise. Java certainly does not have it as part of >> any standard, nor does Linux, as we discussed in the bsh vs. >> beanshell debate in PSARC. >> >> As we're ramping up integration of java components, we're creating >> new gaps from old practice. One of these is the nomenclature >> surrounding the naming of the jar files themselves (jars as >> "libraries"), which I won't go into here. The other is the point >> which Jim raised -- there's currently no expected way to communicate >> stability level other than man pages. Adding man pages to java jar >> projects (projects which deliver only .jars) _feels_ wrong, since the >> consumers of these jars aren't going to expect to find a man page -- >> they're on a very different usage model than most other consumers of >> C libraries and command line interfaces. Consumers in this case >> typically use JavaDocs as their source of API information, and that >> _feels_ like a better place to put that information. >> >> If the man pages are explicitly NOT to be delivered with "jar" >> projects, then where is the stability level expressed?If in >> JavaDocs, then what does that look like, assuming we need precision >> for that nomenclature? >> >> Does the very same taxonomy even apply to jars? The current >> taxonomy is, as a core component of its definition, dependent on >> release versions of Solaris. Obviously, java jar's are more tightly >> coupled to Java versions than on OS release versions, no? >> >>> >>> Thanks, >>> Margot >>> >>> >>> ___ >>> opensolaris-arc mailing list >>> opensolaris-arc at opensolaris.org >> >
OpenSolaris ARC Minutes - 05/12/2009
SYSTEM ARCHITECTURE COUNCIL Layered Software ARC - 05-12-2009 MEETING MINUTES Send CORRECTIONS, additions, deletions to lsarc-coord at sun.com. Minutes are archived in /shared/sac/Minutes/LSARC. ATTENDEES: Chair Margot Miller Yes Members (8 active members) Mark CarlsonNo Lloyd Chambers Yes Aniruddh Dikhit Yes Danek Duvall(on sabbatical) John FischerYes Ed Hunter Out Chris Kasso no Arieh Markel(on sabbatical) Jyri Virkki Yes Interns Brian Cameron Yes James Gates no Irene Huang no Matthias HuetschYes Michael Kearney Yes Linda Schneider no Rahul Shah no Krishna Tallapaneni no David Tong no James WalkerYes Mark Martin no (external) Coordinator Asa Romberger (PM) Yes Guest Not all attendees names are captured. Please send email to Asa.Romberger at Sun.com, if you attended the meeting and your name was not captured. == AGENDA 05/12/2009 10:00-10:20 Open ARC Business (use open dial in above) == Case Anchors: == ARC Business Fast-tracks: Case(Timeout) ExposureTitle 2008/748(05/08/09) openDrools extend timer to 05/15/09 2009/239(05/08/09) opentipc Ver 1.7.6 approved 2009/258(05/08/09) openpywbem Ver 0.7 approved 2009/262(05/05/09) opentrove-2.0.4 extend timer to 05/15/09 2009/277(05/10/09) openlibosip2 extend timer to 05/15/09 2009/278(05/11/09) openqdox-1.9 extend timer to 05/15/09 2009/280(05/11/09) openjrexx-1.1.1 extend timer to 05/15/09 2009/296(05/15/09) opencommons-collections let run 2009/298(05/18/09) openlogilab-common let run 2009/299(05/18/09) openlogilab-astng let run Opinions Other stuff --- Next Meeting -- 05/19/2009 10:00-10:20 Open ARC Business (use open dial in above) 10:25-10:40 Closed ARC Business (use closed dial-in)
LSARC/2009/250 - Firefox 3.0.x on Solaris 10
All, Attached please find the updated proposal. I have reset the timer for Wednesday May 20th, 2009. Thanks, John John Fischer wrote: > All, > > I am putting this case into need spec status to allow the project team > to produce a new specification that addresses the sharing of the Gnome > libraries and installation locations. Once this is done I will restart > the timer appropriately. > > Thanks, > > John > > Abhijit Nath wrote: >> Alan/John, >> Yes, it is a mistake. We'll shift all the private libraries/ Firefox >> 3.0.x libraries in "/opt/firefox3". >> You are also correct about the LD_LIBRARY_PATH. We'll modify the one >> pager and incorporate LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64. >> >> Some other frameworks' up-prive (eg GStreamer) also need upgraded >> gnome libraries( Refer Brian's mail). So we are in a process to check >> the feasibility of keeping all the upgraded libraires in a common >> place. We'll revert back asap. >> >> Thanks, >> Abhijit >> >> On 04/22/09 04:40, John Fischer wrote: >>> Alan, >>> >>> I totally missed the /opt/firefox and /opt/sfw issue. Thanks for >>> catching that one. >>> >>> I'll let the project team address these issues. >>> >>> Thanks, >>> >>> John >>> >>> >>> Alan Coopersmith wrote: >>>> John Fischer wrote: >>>>> This project proposes to back port Firefox 3.0.x from Nevada to a >>>>> Solaris 10 Update release which is a Patch release of Solaris. >>>> >>>> Is it integrating into the update release or shipping as a separate >>>> web download running on top of the update release? (/opt would be >>>> wrong for the integrated case, right for the unbundled case). >>>> >>>> Is this intended to replace or supplement Firefox 2.x? >>>> >>>> The one-pager references both /opt/firefox3 & /opt/sfw/lib/firefox/ >>>> - can >>>> we assume /opt/firefox3 is correct since /opt/sfw is reserved for the >>>> Solaris Companion CD? >>>> >>>>> All the plugins are spawned by firefox-bin. So, LD_LIBRARY_PATH >>>>> environment variable will be set to /opt/sfw/lib in run-mozilla.sh >>>> >>>> This also seems incorrect - should this refer to the /opt/firefox3/lib >>>> directory or are you importing/depending on libraries from the >>>> Companion CD? >>>> >>>> (Also, in the unavoidable cases in which you must use >>>> LD_LIBRARY_PATH-type >>>> variables, you should always use LD_LIBRARY_PATH_32 or >>>> LD_LIBRARY_PATH_64 >>>> to avoid breaking programs of the other wordsize.) >>>> >>>> Are the library upgrades incompatible? Is there no way they can be >>>> shipped as updates to the existing public libraries in /usr/lib ? >>>> >>>> For the brand new libraries, like cairo & dbus, is there any >>>> architectural >>>> reason they must be private, or is this just a resource issue around >>>> supporting >>>> them? >>>> >> > ___ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org -- next part -- An embedded and charset-unspecified text was scrubbed... Name: proposal.txt URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090513/2f3589b7/attachment.txt>
pywbem Ver 0.7 [LSARC/2009/258 FastTrack timeout 05/05/2009]
Python 3.0 has been ARC'd, but hasn't delivered yet. You can ARC the python 3.0 pywbem interfaces now, but presumably you want python 3.0 to deliver them. -Norm Vivek Titarmare wrote: > It's Ok. I will re-add the 3.0 version to the prototype_com > > Best Regards, > ~Vivek R. Titarmare > > -Original Message- > From: Danek Duvall [mailto:Danek.Duvall at Sun.COM] > Sent: Wednesday, May 13, 2009 1:51 AM > To: Vivek Titarmare > Cc: 'Margot Miller'; LSARC-ext at sun.com > Subject: Re: pywbem Ver 0.7 [LSARC/2009/258 FastTrack timeout 05/05/2009] > > On Tue, May 12, 2009 at 06:22:32AM -0700, Danek Duvall wrote: > > >> On Tue, May 12, 2009 at 06:40:42PM +0530, Vivek Titarmare wrote: >> >> >>> I have updated the prototype_com file to just have Python version 2.6 in >>> it. Below are the contains of the file. >>> >> Looks fine to me. >> > > Actually, I was wrong when I said before that we didn't have 3.0; I'm not > sure why I forgot about that. The prototype file you sent out with the 3.0 > bits in it looked fine to me, once that's taken into account. > > Sorry for the confusion. > > Danek > >
