Hi Jeff, Thanks for the quick response.
Please see my responses inline. Thanks and Regards, Seema. Jeff Trawick wrote: > Seema Alevoor wrote: >> Draft for the integration of APR and APR-util 1.3.2 and updation of Apache >> 2.2 version to 2.2.9 >> is at >> http://wikis.sun.com/download/attachments/7077996/apache229-apr-apu132-arc-case-draft.txt >> . >> > a few comments, mostly on stuff inherited from previous ARC cases > > >Apache 2.2.9 ChangeLog can be found here: > > http://apache.deathculture.net/httpd/CHANGES_2.2.9 > > canonical 2.2.9 change log location: > http://www.apache.org/dist/httpd/CHANGES_2.2.9 (sounds better than > "deathculture.net") > Changed it. > 4. Apache Internationalization. > > Apache2 provides GNU iconv compatible I18N support via > libaprutil-1.so.0.2.8. The integration proposed in this FastTrack > relies on the GNU iconv compatibility layer available in Solaris' > libc.so. > > > libaprutil-1.so.0.2.8 won't be the new name ( ...0.3.2 ?) You are probably referring to the old Apache ARC case material. In the current draft, it is libaprutil-1.so . > > I'm curious of the meaning of "GNU iconv compatibility layer" in this > context. This was from the previous ARC case. Earlier (probably in S8 and S9 days) GNU applications had issues with Solaris's iconv(). But, it is not the case now. Maybe it made sense in the past to include this phrase, but since it no longer makes sense, I have removed it from the current draft. Thanks for pointing it out. > 6.1. Interface Stability > > Compatibility between the minor release family of APR, APR-util canonical > distribution is not guaranteed. We will classify APR, APR-util Interfaces > as Uncommitted. > > I think we should promise as much as apr does, and regression test for > that with frozen binaries and Apache modules. Otherwise third-party > providers of binaries who bother to read the details may be disinclined > to claim support for the web stack. > Since we don't fully own and control the source, we can't guarantee the stability. Hence, most of the interfaces in existing components are Uncommitted. But if the component has been found to be stable (never introduced any compatibility issues in the past e.g., Apache had broken the compatability between 2.0 and 2.2) then I think, we can assume the same would be true in future and hence classify the stability level as "Committed" (e.g. MySQL 5.x). > apr won't remove interfaces until the major version changes. apr won't > add interfaces until the minor version changes (more conservative than > is usually necessary). What is this in terms of "Interface Stability" > terminology? I think, it will be "Committed". http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/#Policy has more details about the interface taxonomies. > Nothing is said here about httpd interface stability. That is covered in the httpd ARC case : http://www.opensolaris.org/os/community/arc/caselog/2007/586/materials/apache-txt/ > -/- > > Is there a separate document with considerations such as > - which apr/httpd features [not] provided Bugs are used to keep track of missing features or modules. And these changes would mostly require additional ARC case to be filed. So, doc would be the ARC case material. > - which support libraries chosen and why (e.g., native LDAP vs. > OpenLDAP, and implications for plugin modules) AFAIK, the native (OpenSolaris) one is always preferred. In case of native LDAP and OpenLDAP, there is a bug against native LDAP support (CR 6609048) and so we are using OpenLDAP.
