I've consolidated issues related to this as
http://track.sipfoundry.org/browse/XX-6483
and scheduled it to be addressed in 4.2. If you have additional
information to add regarding changes that the upgrade made that you
think are inappropriate, please add them as comments on that issue.
Please don't use the issue as a forum to argue about whether or not
changes should have been made - let's stick to the facts for the
moment.
The changes that were made with respect to OS dependencies and upgrades
were well-intentioned: they were designed to ensure that any sipXecs
system deployed in the field would as closely as possible resemble the
systems that had been through the QA process the central development
team has in place. However, it's clear that those changes violated some
equally valid expectations of system managers in the community, and in
that light we will reexamine some of our installation and upgrade
strategies. Watch the issue above for details.
A few statements to clear up some things from this thread:
* It is perfectly valid to install a system from RPMs alone
without using the ISO image.
Understand that the QA process (aside from upgrade testing) is
primarily based on the ISO images: if you want to ensure that
what you get is as close as possible to what has been through
the project QA process, use the ISOs for new installs.
Ideally, we should do a better job of making the dependency
declarations in our RPMs be more specific; we'll look at that in
the context of this issue.
* Our distributed RPMs should not modify files 'owned' by other
RPMs, and at least in the open source version, should not
obsolete RPMs from other sources unless it is absolutely
required for us to work (as in an operational incompatibility).
A couple of the current RPMs do these things, and we'll change
that. This was a little too heavy-handed way of accomplishing
the goal - we'll find a better way (and possibly that will mean
more risk for those building a system from multiple sources -
we'll try to air those tradeoffs when we assign someone to this
issue and in the installation documentation).
* More specifically - our RPMs should never modify any
local yum configuration that our RPMs did not create.
* With respect to differences between the open source and
commercial versions; the following are all true:
* They are almost entirely the same sources. There are
some features in the commercial version not in the open
source version (the number rises and falls from release
to release, but it's a trapdoor - once something has
been released as open source it stays there).
* The commercial builds get much more time and attention
from our internal QA team than the open source builds do
(is anyone surprised by this?). This is one of the
benefits the commercial customers get - the flip side is
that they get the releases a little later than the open
source community does.
The builds are close enough that testing most features
in one is a valid test of those features in the other,
and this works both ways - keeping this true is an
important part of the economics of how open source
benefits the commercial product, so we have a strong
incentive to keep it true.
* The commercial version of the update repositories is
much more tightly controlled and comprehensive than the
open source repositories are - another benefit of the
commercial version (or a disadvantage, if you favor
speed over having a single source of tested updates).
All of the above are also true of other well-run commercial/open
projects and distros. The sipXecs community is to the
commercial versions what Fedora is to Red Hat Enterprise - the
open source community gets a slightly less stable but free
product faster, the commercial customers get additional
stability and other benefits of a vendor behind the product.
If anyone out there is laboring under the illusion that you're getting
something for nothing with sipXecs: you're wrong - you're paying with at
least some additional risk, with your bug reports, and with your other
contributions. I like to think this is a good deal for the open source
user community, and I know that it's a good deal for the companies that
do commercial versions.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
