rahul wrote: > > > Earlier in this thread mod_jk, mod_fcgid and > > mod_security were all > > Uncommitted, looks like the latest proposal > > downgrades them all to > > Volatile? What changed? > > I did not understand the complete ramifications of Uncommitted and > Volatile earlier. After you had pointed out them to me, It is > obvious to me that these modules do not _guarantee_ that their > versions will not break compatibilities. (As you can see from their > replies). They also make it explicit that there are situations where > they will have to.
In general one can never guarantee breakage is impossible unless one owns & fully controls the source, which is not the case for any of these SFW/Web Stack components. Nonetheless, most of the interfaces in existing components are Uncommitted. The reason is that while there is no forking, there is a separation between the upstream releases and the bits integrated into OpenSolaris. If an incompatible 2.0 [using made-up version numbers here] of a previously integrated 1.5 is released upstream, nothing forces it to be immediately integrated here. It may be that the 2.0 is never integrated into the [mythical future] Solaris 11. Same applies for any of the upstream releases, so even if an entirely incompatible 1.5.0.1 comes out, there is no requirement that it must go into OpenSolaris and break compatibility. Of course, there are tradeoffs. If indeed the next upstream bugfix breaks interfaces, the choices are to stay back and live without the fixes or backport individual fixes without backporting the incompatible parts. Volatile is discouraged since it means nobody else can reliably make use of the component. Which raises the question, why bother including it? (And there are sometimes good answers as to why do it, so just raising the question doesn't mean it's not the right answer ;-) Do expect some level of ARC pushback on Volatile interfaces. >From the discussion so far, mod_dtrace sounds clearly Volatile given that it is early and experimental and expected to change quickly. On mod_fcgid I don't have enough info; mod_security and mod_jk are well-known and widely used and we probably want to encourage their use in OpenSolaris. Ultimately the "project team" needs to understand the upstream component & their delivery history enough to weight all these pros & cons and determine how the project team will handle version upgrades if upstream incompatibilities occur. A key point is that the stability guarantee is from the project team integrating into OpenSolaris, not from the upstream community. Of course, the practices of the upstream community are a very important factor to consider, but not the only one. With all that general background... Rahul since you are the project "team" for these modules, it's your decision on what to propose for the ARC case. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
