Yes and I did not mean to skip and forget all of the other folks who contributedHere is an account of the history of the technology http://blogs.gridengine.com/content/history-sun-grid-engine and my team's 20+ years of involvement. As Chris writes: Have you looked deep into the codebase? TheThis is very true. When we hire a new engineer then we know by experience that it will take that new hire at least two years to become an effective Grid Engine developer. If it comes to the guts of the scheduler or the qmaster then the time required before we entrust major changes to them is yet much longer. Therein certainly lies one of the key reasons why code contributions from the community have been so small. In the ~9 years of the Sun sponsored open source project (and not taking into account the proprietary CODINE/GRD history before) only 3% of the check-ins came from the community and that amounted to only 1% of lines of code being contributed. The rest came from Sun developers, i.e. my team. Those 1% are roughly 30,000 lines (added / deleted / changed as reported per our open git repo) and within them was one larger feature which some of you may be using. It was the array job interdependencies contributed by Rising Sun Pictures (RSP). It was a functionality they were requiring for their visual effects workflows. We had no time to implement it any time soon so we gave them guidance and they did the implementation. Another larger contribution (almost half of the lines of code contributed by the community) came from a former collaboration partner of ours back from the GRD times. One main piece he contributed was an interface layer in the scheduler which he introduced so he could plug-in proprietary code of the company he was working for. I don't know whether this interface layer ever got used for anything else (we certainly didn't use it and also don't expose it). A much bigger contribution to open source Grid Engine came later and it came from Univa: When we switched from Oracle to Univa we took what was left behind by Oracle (an interim and unstable state between 6.2u5 and the later Oracle-proprietary 6.2u6) to create our 8.0.0 which we open sourced (https://github.com/gridengine/gridengine). This was an effort to solidify the code base, to fix the most nagging issues we knew about from our work on the Oracle-proprietary 6.2u6 and 6.2u7 releases, to make a few focused enhancements like rewriting interactive job support which was pretty broken in 6.2u5 and to drop old code "baggage" which we knew we wouldn't want to maintain going forward. This resulted in >600,000 lines of code modifications (again: added / deleted / changed as per our git repo). If you are using Son of Grid Engine then this is the basis of what you are using and on top come the very respectable efforts of Dave Love who is shepherding that version. How much dedication as well as effort and experience (and thus investment) is required to fundamentally evolve the Grid Engine technology is probably best exemplified by the very personal account of our long-time team member Ernst Bablick about his project introducing Job Classes into Univa Grid Engine 8.1 (http://ernst.bablick.de/blog_files/jc_introduction.html). Not far from 30,000 lines of code modifications were required for this alone plus all the know-how which Ernst has. This is what I was referring to in my original post in this thread: The Grid Engine engineering team always has been a tightly knit group, even prior to the days of joining Sun in 2000 and then throughout all the years at Sun, the one year at Oracle and now since Jan 2011 at Univa. Our dedication and passion is to evolve the Grid Engine technology and help Grid Engine users to apply Grid Engine successfully in their various use cases.Thanks, Fritz
--
|
Fritz Ferstl | CTO and Business Development, EMEA
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
