This is an interesting thread. I say that because I am wondering since my last update to 4.02 how broken my Centos installation is now.
I will go as far as being o n the record here and stating "I don't think it is reasonable to "break" the ability of any system to update its OS or to downgrade it without an admin acknowledgement". From an Open Source standpoint I can't find a usable Centos 5.2 repository. I also don't think it's reasonable to update a package and "break" a built-in function of an Operating system without disclosure beforehand. Whether it was intentional or not, it's problematic that this happened, of course this is my opinion. There are a lot of safe superadmins out there that test an upgrade before deciding it is supportable or advisable to install it. Since most of my sites run Centos 5.3 and my test upgrade to sipXecs 4.02 breaks the OS and any yum updates in the future, I see a lot of stuff sitting at sipXecs 3.10.3 with features I can't upgrade to because of one reason or another, but none of the reasons are OS related. At the same time I am the person who raised the issue that the ISO install didn't provide YUM repo's for Centos. I am completely perplexed at the decision to have an upgrade "forcibly downgrade" and pretty much break a system, and become. I never saw those notes in any of the related JRA issues. Obviously if the development group feels like it's a reasonable decision to lock the OS version to a specific release, I feel that's fine for the commercial version. Assuming this logic is required for the open source version, why bother trying to support builds or installations on any other OS version or release? Realize locking the OS release int he Open Source version without available repo's for that release is again, problematic. This all being said, I am very confident I can ascertain how to resolve the yum issue in time, but it makes me less likely to jump in first try to try perform an upgrade. I for one like to discuss, help and contribute. I do this regularly, because people help me too. That being said, let's try to work this out before people start slamming the developers with unneccessary JIRA issues and people start feeling like red-headed step children. Should there be a discussion to put this into the perspective that it will not break (IMO) critical OS functionality? Or is it more reasonable to think, as is the indication I get from this thread, that sipXecs should move towards a "no deviation from" the OS enviroment as provided (ala' Jumpbox)? Please take these comments as a solicitation to encourage helpful dialogue and to illicit information before the point of "why did that happen". Tony >>> "Marden Marshall" <[email protected]> 09/12/09 9:41 AM >>> On Sep 12, 2009, at 3:43 AM, Alberto wrote: Ask yourself one simple question; What is more important, to have the latest and greatest versions of Firefox, Gimp, etc. or to have a thoroughly tested and reliable PBX system? If the answer is "a thoroughly tested and reliable PBX system", then you will stay with our OS recommendations and use CentOS 5.2. Better yet, pay for a commercial license and as a supported customer you will also be provide with ongoing security updates for the supplied OS. Hi Marden, no need to say in my CentOs PBX system I don't have Firefox neither the Gimp. The real point here is: I'm happily running CentOs 5.3 and I installed sipxecs via yum, it's a recommended best practice to change CentOs repos to version 5.2? Could it lead to some untested OS incompatibilities between versions? That of course might cause the system not to be thoroughly tested as wanted? Said that: you are in perfect right to manage repos file if sipxecs was installed from the iso. And again you are in perfect right to ask me to install a production system using only CentOS 5.2 or simply stick to the version distributed with the iso. But I believe you cannot predict why some user is using CentOs 5.3 or 5.1. They might support other software with different requirements on the same box. I believe there are many reason that should suggest to leave this decision to the admin. We do not support a "clean install" of sipxecs via RPM's. The RPM's are only provided to allow a user, who has previously installed sipxecs using our supplied ISO, to perform a software update. Therefore, to first install some random version of CentOS and then to install sipxecs via RPM's, you do so at your own peril. Don't like very much the statement about buying a commercial license. Is the commercial product thoroughly tested against every possibile OS software update? Was not the commercial product based on the same code based of the open source one? What is compatible with last OS update on the commercial product, which I believe could be a super-set of the open source one, shouldn't be compatible with the open-source? For our commercial product, SCS, we supply the customer with the OS and SCS software bundled together, i.e. an ISO install. We then provide the customer with ongoing OS updates for their installed system. These updates are supplied directly from Nortel's own repositories, not from CentOS repositories. For example, when we released 4.0 (SCS 3.0), we also included an OS upgrade which brought the customers servers from CentOS 5.1 to CentOS 5.2. If we deem that it is beneficial to our customers, we will, in a future release, upgrade their servers to CentOS 5.3, etc. In all cases, we only release these OS updates after they have been thoroughly tested in conjunction with the SCS software and our recommended server hardware. What I see here is an unnecessary and potentially disruptive obsession over what version of OS is running on ones PBX. Do you worry about which version of VXWorks OS is running on your Polycom phone or which version of Linux is running on your Snom phone? I'm certain that you do not. Instead, you rely on the vendor to deliver a solid working combination of OS and application software. That is exactly what we are trying to accomplish here. </[email protected]>
_______________________________________________ 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/
