Raptor 1.4.19 [LSARC/2009/419 FastTrack timeout 08/12/2009]

[Brian Cameron]

Mark:

> Brian Cameron wrote:
>>
>> I am submitting this case for Raptor 1.4.19 by Jerry Tan, and it will
>> timeout on August 12th.  See attached onepager.
>>
>> Brian
> <...excerpted from the attachment...>
>>     4.5. Interfaces:
>>                 Exported  Interface
>>     Interface                          Classification         Comments
>>     -----------------------------     --------------  
>> ----------------------
>>     SUNWraptor                        Uncommitted     Package name
>>     SUNWraptor-devel                  Uncommitted     Package name
>>     /usr/bin/rapper                   Volatile        parser utility
>>     /usr/bin/raptor-config            Volatile        config utility
>>     /usr/lib/libraptor.so.1           Volatile        library
>>     /usr/share/man/man1/rapper.1      Volatile        man page
>>     /usr/share/man/man1/raptor-config.1 
>>                                       Volatile        man page
>>     /usr/share/man/man3/libraptor.3   Volatile        man page
>>     /usr/lib/pkgconfig/raptor.pc      Volatile        pc file
>>     /usr/include/raptor.h             Volatile        Header file
>>     /usr/share/gtk-doc/html/raptor    Volatile        help file
> I notice that most of the exported interfaces are "Volatile".  This 
> seems low, especially since the upstream itself seems committed to 
> stability (e.g. the notice regarding the ABI/API change on the front 
> page).   Isn't "Uncommitted" more appropriate?

I will leave this question for Jerry to answer.

> Also, is this *library* racing another FOSS product  -- i.e. will we see 
> another consuming application show up soon?  I ask merely out of 
> curiosity -- I believe we have a pattern of delivering (FOSS enabling) 
> libraries in LSARC, whereas PSARC often challenges libraries without 
> consumers.  And this seems like such a specialized library. . .

My understanding is that this library will be used in the next release
of Tracker that we ship, thus the need to integrate it.

> Also, another point of personal clarification -- I notice not all 
> projects complete a FOSS checklist.  This one didn't seem to.  I suspect 
> that's fine, except that in this particular case, I couldn't find a 
> binding level.  I notice that's an explicit question in the FOSS 
> checklist, but reviewing many recent one-pagers reveals that this detail 
> is very often omitted.   What is the binding level here?

This case is intended to be included only in future releases of Nevada,
so a minor release binding.

> One final nit -- are we really interested in delivering raptor.pc?   
> It's not really been common practice up until now to deliver those 
> ./configure artifacts.

The pc file is not a configure artifact, it is an input file into
pkg-config.  If you look in the /usr/lib/pkgconfig directory, you
will notice that most free/open source modules provide pc files so
that other modules can identify if the dependency is on the system,
what version is installed, etc.

Brian