Irene, Support for an interface has no barring on the EOF process. For Committed and Uncommitted interfaces one must go through the EOF process. For Volatile interfaces it is a little bit more difficult to discern when to follow the process and not. For example, if the security team were to remove OpenSSL they would need to go through the EOF process because they have so many projects depending upon them. If sfw decided to remove the animate binary from /usr/sfw then they could probably do so without the process.
Which interface(s) are you concerned about? Thanks, John Irene Huang wrote: > Brian > > Is EOL/EOF required for all interfaces? > My understanding is that EOL/EOF process is only required for Supported > interfaces. > > --Irene > Brian Cameron wrote: >> >> Jedy: >> >>> libsexy has already been ARC'd so I guess the package name has already >>> been registered. >> >> Oh, I see, this was ARC'ed along with Compiz and the package names are >> SUNWlibsexy and SUNWsexy-python. >> >> http://sac.sfbay/LSARC/2008/115/proposal.txt >> >>> Putting many libaries into one packages will redcuce the number of spec >>> files but will increase the build time and the difficaulty of updating >>> a single library. Leaving the library alone will introduce complicated >>> dependency and we have to maintain more spec files. ???Do we have any >>> policy to handle this situation? >> >> The advantage of lumping multiple modules into a single package is that >> it can help to avoid needing to go through the EOL/EOF process when >> something is removed. >> >> For example, we currently have libgweather in SUNWgnome-panel. If, >> in the future, libgweather were to go away, then we can remove it >> without affecting any package names. >> >> Since package names are normally "Uncommitted", if we have libgweather >> in its own separate package, then you need to go through the EOF process >> when it is removed. >> >> So, it is generally not a good idea to put something into a separate >> library if you know it is likely it will go away. Highly volatile or >> private libraries are typically the best candidates for libraries to >> be bundled into a multi-module package. >> >> On the other hand, libraries that are commonly used outside of the GNOME >> stack (e.g. dependencies such as GnuTLS or libexif) make better sense to >> have in separate packages. >> >> So, Jedy, we have two choices: >> >> 1. Submit an ARC FastTrack to specify that you plan to integrate these >> interfaces into a different package than was previously specified >> in the Compiz case. Then we could bundle it into SUNWgnome-base-libs >> or SUNWgnome-panel. >> >> 2. Add the new package specified in the Compiz ARC case with the >> understanding that you (or someone) will need to go through the >> ARC EOL/EOF process when we want to remove the package. >> >> Really #1 is less work since you have to give 1 years prior >> notification when you EOL/EOF. Avoiding the hassles of approach #2 >> was the motivation for multi-module packages. >> >> Brian >> >
