Oh, boy. Where to begin. First of all, I don't have a clue how this discussion got out of hand. We started out with a simple issue that showed up on a CentOS box. It couldn't compile the recently released OSG 2.8.1 version. The issue came down to the fact that CentOS and Red Hat Enterprise Linux only have a 2.4.5 binary version available. There was friction between the community that said to just upgrade to 2.6, and the CentOS users and administrators that tried to explain that it is difficult to do that in a large enterprise environment. I jumped into this thread to try and help both parties understand the needs of the other. Instead of a calm resolution, I've now been subjected to a rant from the OSG czar who says I need to contribute more.
Responses inline below: Robert Osfield wrote:
The loss in perspective is that the illusion that RHEL/CentOS and all the other long term supported linux distributions can bundle not only the core operating systems but ten's of thousands of other open source tools as one single supported and consistent entity. No other operating system vendors attempt to do this - they just ship the operating systems and the all the rest of the tools are provided by extra separate entitities and typically provided by 3rd parties. Some of these third party apps might rev at the same rate as the underlying OS, but typically don't.
I find it odd that someone who uses and advocates Linux as much as you would question the practice of bundling the OS and applications and supporting them. It's not just Red Hat and CentOS that do this. Pretty much every Linux distribution does it. In the case of the Enterprise distros, the support comes from paid contracts which help with security fixes, and addressing any critical problems that arise. In the case of the free distributions, the support comes from the community. In reality there's not much difference in software between Red Hat Enterprise and Fedora. RHEL 5 matches up almost exactly with Fedora 6, for example. The difference is in the frequency of releases, the continuous support with minor bug and security fixes (often back-ported from upstream revisions), and the ability to centrally manage updates of client systems (when new updates come out, you just log on to a web site and press "Go", and all of your workstations are magically updated).
Now it's very cool that linux distributions do attempt this almost impossible feat, but and it is humongous but there are problems with this approach of bundling practically everything together and rev's at the same rate is that in the 3rd party vendors can't be expected to pay for the support for this locked in versions of their software for the benefit of the linux distribution vendors.
Of course not. The customers pay the distribution provider for that support. In turn, the distribution's own developers and engineers work with each 3rd party provider to integrate those packages into the distribution successfully. OSG is not part of RHEL, which is probably why you haven't heard from any of them.
I'm also not sure why you think this is an "impossible feat". It's actually a well-formed engineering process that works quite well. Major issues are very rare and usually isolated to a small set of users, and Red Hat addresses the problems in a matter of days.
This very thread is about that fact that CentOS/RHEL have locked in versions of software that is DIRECTLY cause support work for us - not just the CentOS/RHEL users, but others who have nothing to do with developing or supporting this distro's. You might pay RHEL for support for doing this but are you paying all the rest of the ecosystem like OSG community members for the luxury of you using the tools that only come with a particular RHEL.
I don't understand this claim at all. If you actually read my last e-mail, I pointed out three possible solutions, only one of which involves any effort from you or the OSG community. Please understand, we're really happy that you've supported the older CMake versions thus far, but we know that it's entirely your prerogative. If you decide that supporting CMake 2.4.5 is too much work to continue, we'll be happy to stick with OSG 2.8 until the next version of Red Hat Enterprise is released with a more suitable version of CMake (or we'll make an exception and install a non-standard CMake version if the need becomes great enough). As an example, we just recently upgraded to OSG 2.8 from 2.2. This is how most of the software on these distributions works. As another example, we still develop with GTK 2.10, even though 2.16 was released some time ago.
We may be missing a few new features introduced in the new revisions of libraries like these, but we know for certain that our code will still work and that our customers' needs will be met. When someone is paying you to develop and support a large software system, it's a nuisance to deal with the feature creep that comes along with updating multiple dependencies several times a year. When you're developing and supporting several such systems at the same time, it's simply impossible.
I expect you're now thinking that you'll have to deal with extra support for us as we use an older version of OSG, when the problems in question would likely be fixed in newer versions. I challenge you to find an instance when I have ever asked you for such support. Our experience has been that we have fewer headaches if we only upgrade OSG (and deal with the resulting changes in our own libraries and applications) when we have time to spare. As consistent as you tend to keep the API between versions, there are always a few issues that come along with upgrading to a new version. We've found it more efficient to only upgrade when our project work is light enough that we can address all of these potential issues at once. If we upgraded to every new revision as it is released, there would be more work to do and less time to do it.
Aside from this, the branching scheme you and Paul have recently implemented goes a long way to addressing the issue of upstream bug fixes, so the potential support issues are further minimized.
So this is perspective that is missing. It's your companies choice to use a distro with locked in versions of software, and there is a cost of this that goes far beyond your own company. Who's to pay for this?
I disagree. There is no such cost, as I explained above. The only time you need to spend on us is the time it takes to decide to continue support for CMake 2.4.5 or not.
In the case of community like this core developers have to put up with support hassles like this as just part of running a project, but we need help, and help specifically from people who wish to use locked in versions of software due to using CentOS/RHEL etc - you guys need to spend the time in properly supporting software that you need, this means allotting time and resources to help out with testing.
I have to say, this really makes me angry. By my count, just this last week I answered 12 messages on the list, and I answered over 40 in the last 30 days. I recently talked my sponsors into letting me contribute some code that was developed on their dime to OSG (namely the .bsp, .mdl, and .vtf plugins for Half-Life 2 maps, models, and textures). I've also contributed several bug fixes in the past. Every day, I do my best to keep up with the mailing list, just so I'm aware of what's going on with OSG. It helps us keep up with the new features that we might use, and it also lets me help others using the knowledge I've gained over the years. I've even caught heat from my supervisor for spending too much time on the mailing list and running various OSG tests, when I should have been doing my project work. I did all of this because I believe in what the OSG community is trying to accomplish. Maybe all of this doesn't sound like much to you; I realize you answer a lot more e-mails than I do, and I realize that there are a lot of contributors ahead of me in the authors list. I assure you, however, it's a significant effort for me. Reading comments like this almost makes me wish Performer were still around (almost).
Despite your lack of gratitude, I'll continue to contribute whenever I can. Not because you're telling me to, but because I still believe in the OSG community and what it's trying to accomplish. I've been working with OSG since version 0.9.2, and looking back, it's amazing how far we've come. You've got a lot to be proud of, Robert, and we're all very fortunate that you (and Don) decided to make this wonderful software available to all of us. At the same time, you've also got a lot of people that supported and continue to support you, and I implore you to treat them with respect. We do what we can to keep this train rolling, but we can't all eat, sleep, and breathe OSG like you do.
For instance we have the CDash dashboard to tracking nightly builds. Also talk with your management about this issue - if you want the luxury of using a fixed version of OS and associated tools then their is this extra cost that you need to factor in, if you don't have the ability to keep track of supported software then you have to pony up the 3rd party support to cover this.
You keep throwing this "luxury" word around as if we're programming on gold-plated computers or something. Please be aware that running an enterprise distribution actually */saves/* us money. Without it, we would probably have to hire a dedicated IT person to manage our network, instead of taking care of it ourselves, which means we wouldn't be able to do as much real work as we do now. We work at a state university. Our state budget has been cut by 25% over the last three years. Our University is now in the process of implementing layoffs, shutting down entire degree programs, downsizing the faculty, and re-allocating the students to different majors. This has never happened before in our 46-year history. We're not rich. Paid support for OSG is not even close to an option for us.
Open-source projects work because people contribute to a common cause. The flip side of this is that no one is entitled to anything. If I need you, Robert, to implement some new feature in OSG for me, I can't expect you to do it out of the goodness of your heart. That's what OSG Professional Services is for, right? By the same token, you have no right to expect me to drop all of my responsibilities and test a revision of OSG just because you decided that it's a good time to release. If you want to pay for some of my time to test every new revision of OSG on all of our platforms, we'll be happy to work something out, but I don't really expect that this is an option for you, either.
I do hope you'll continue to support RHEL, CentOS, and other enterprise distributions. For my own selfish reasons, sure, but also because I believe it's healthy for the project to keep itself available to as many people as possible. I do understand your concerns and frustrations when not enough people come forward with testing at the times you need them the most. I think this comes with the territory of open-source software, though. Everyone does the best they can, but no one can really be counted on for anything. For my part, I've glanced at the CDash site in the past, but I haven't had the chance to make myself familiar with it yet. If it would help as much as you say, then I'll make an effort to get involved with it as soon as I can. If someone familiar can e-mail me a quick-start guide (or a link to one), that would help.
Now, can we please come to a peaceful resolution here? I really like working with OSG most of the time, but these past few days have been a challenge.
--"J"
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
