Hi, Mark. please see my comments inline. thanks.
Mark Martin : > 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? From its release note and changelog, http://librdf.org/raptor/RELEASE.html#rel1_4_19 "New development will move to raptor 2 where a planned ABI and API break will happen" So I would rather call it as "Volatile". > > 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. . . Tracker, one desktop search tool, see LSARC/2008/375/ its new version (maybe 0.7.0) is depending on libraptor. the release date is not fixed, but hopefully it will be released by the end of this year. so I made this ARC case to integrate its new dependency. > > 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? > From FOSS checklist Document " After the check list is completed the project team should be able to determine if a project can be automatically approved. This will occur if all checks result in no "ARC review required" answers. " This ARC case is made by my team to request ARC review, so we did not complete a FOSS checklist. we plan to integrate raptor 1.4.19 into NV. > 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. raptor.pc is needed. In fact,a library bundled one pc file is recommended, since pkg-config can use it to get CFLAGS, LIB flags. and pkg-config is used very often. IMO, raptor-confg , which can be used to get CFLAGS and LIBS , will be removed in its future version. since release a pc file is more common.
