Jerry Tan wrote: > 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". > But that's for a new major release of raptor. It mentions the next revision is targeting a stable interface. That's fine -- you've considered it, so I'll move along. >> >> 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. Got it now, thanks. >> >> 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. > OK, I see. Although I understood the intent and nature of the FOSS checklist, I was never fully clued in on when it was an absolute necessity or what the guidance was on filling it out. It sounds like it's a tool when you're not quite sure whether to fast-track or not, but if you're certain from the get-go, then it's not required. I'm suppose I'm OK with that.
> >> 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. > > Well for good or bad, I've noticed .pc files before, questioned them, and the teams have simply removed them. Knowing now that they're part and parcel for projects is fine, so I don't have a problem if providing them is a norm. Something to note here is that it seems like a somewhat emergent interface artifact standard, and that it's probably safe to *expect* this build configuration interface to be present for most FOSS type projects, much like header files or libraries. Is there any internal guidance or documentation on this, or is this just an unspoken common practice among teams nowadays? We might want to make sure that this expectation is communicated to external contributors and systems as well (e.g. SourceJuicer).
