Igor Galic wrote: > > > Those are only a few of the examples, I hope they clarify in which > direction I was heading.
[Sorry, snipped examples for brevity, if reading via archived check previous post for details.] The important bit is that the OpenSolaris Web Stack project does not fork the upsteam distributions. For changes which modify default behavior encoded into the upstream component (Apache in this case but this comment applies to all components), those need to be proposed to and processed by the community owning the component. In order for the user experience in OpenSolaris to remain compatible with the upstream we don't patch the source for these kinds of changes (there may be exceptions, in cases where a patch is absolutely necessary for best operation on OpenSolaris... those can be reviewed on a case by case basis). For changes which merely modify the out of box config file, we can look into including those if there is a clear benefit for OpenSolaris. For example, we probably would like to include config entries which make it perform better on OpenSolaris or leverage features unique to OpenSolaris or improve the security of the out-of-box config on OpenSolaris. We probably won't include config entries which alter the upstream user experience just for the sake of altering it. I say probably for both sides since these would have to be reviewed individually to judge their benefit... It is necessary to also submit the changes to the upstream community though. I don't mean to discourage sending such modification requests, please do, and include some thoughts on the benefit to OpenSolaris of each change. Just wanted to give some background on the kind of changes we are more likely to [not] include as local patches vs. handling via the upstream community. -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
