On Wed, Mar 16, 2011 at 2:03 PM, Fritz Ferstl <[email protected]> wrote: > It actually would be > pointless to say anything against forks. They can't be prevented even if one > wanted to.
Thanks for the reply!! And so far, we are not even incompatible forks. Changes in one can be merged into others easily, and they are open & free under SISSL. I think the biggest difference is the approaches in how things are handled in the 3 forks: - Son of Grid Engine: get as many fixes in as possible, including the post SGE 6.2u5 fixes in maintrunk, Open Grid Scheduler's fixes, Univa Grid Engine's fixes, and many patches floating around on the net. - Open Grid Scheduler: only safe fixes can get in, so there are much fewer changes than in the other 2 forks. - Univa Grid Engine: maintain a good core and focus on the value-added (but non-opensource) features, which is needed or else it will follow the same route as Sun Grid Engine. We don't know yet which approach is the best, but like evolution, the best one will eventually be chosen by the users. And during the time period, code and fixes will be exchanged and shared (like the collaboration in the BSD projects). But in the end, the common core is relatively stable, as it has been since 6.0. There are many incremental changes that went in since 6.0, like scheduler as a thread, but the core is still mostly unchanged (resource quota support, advance reservation, pty support all did not touch the core). The core might remain mostly unchanged for the next few more years as Oracle only has half of the team, with the other half at Univa, and yet some open-source developers behind the 2 open-source forks, so there is no one with enough manpower to change the core radically. But then, with scalability to 4000 nodes, 63,000 cores, do we really need to change the core as much?? :-D Rayson > > It was a statement limited to the project associated to gridengine.org and > the source code evolving further in the github repo. So far folks from Univa > have been the only contributors there. > > That in by itself may not be a problem (we have been largely the only source > code contributors in the old Grid Engine project for almost a decade) but we > (the guys who are exchanging message here or the organizations they > represent) have been forming the steering committee associated to > gridengine.org with a reason. > > That was my point. > > Cheers, > > Fritz > >> >> Hi Fritz, >> >> (I always respect you when it comes to things related to SGE, as you >> are the one who took the DQS source from Florida State University and >> commercialized it, which became Gridware& Grid Engine that a lot of >> people rely on in their infrastructure. However, I need to provide a >> different view in this "fork" discussion.) >> >> There are always forks in free software, as "free" is not just the >> price, but the freedom to modify& distribute the modifications, and >> the freedom to fork. Most (if not all?) of the free software licenses >> recognized by FSF& OSI allow forking. As different people have >> different opinions, priorities, and goals, software forks are there >> even in the early stages of the free software era, such as BSD Unix >> from Berkeley -> 386 BSD, FreeBSD, NetBSD, OpenBSD, and the commercial >> BSDi. >> >> And the Open Grid Scheduler was the one who tried to reduce the number >> of forks in Grid Engine. I was not given full access of the Open Grid >> Scheduler until Oracle finally announced that they were ending >> everything on gridengine.sunsource.net late last year. The Open Grid >> Schedule project was there as a place holder from Aug 2010 to Dec 2010 >> with the intent that in case Oracle closes the project, there would >> still be a free version available, but it is not to compete with >> Oracle Grid Engine. >> >> However, I discussed with Ron before related to merging, and besides >> the reason of not seeing the contributor agreement and thus we will >> "stay put", and the other reason Ron raised is that Univa did not >> acquire the intellectual property from Oracle, so Univa's branch is >> one of the 3 forks of SGE. >> >> Last but not least, Dan wanted to join the Open Grid Scheduler >> project, and we will need to check if he is willing to contribute to >> Univa's branch or our branch. Some are more willing to contribute to >> open-source projects than open-core projects, and this is a well known >> fact that a lot of the open-core projects are mostly backed by the >> company-hired developers. >> >> Rayson >> >> >> >>> >>> Cheers, >>> >>> Fritz > > -- > Fritz Ferstl -- CTO and Business Development, EMEA > Univa -- The Data Center Optimization Company > E-Mail: [email protected] > Web: http://www.univa.com > Phone: +49.9471.200.195 > Mobile: +49.170.819.7390 > > > --------------------------------------------------------------------- > > > Notice from Univa Postmaster: > > > This email message is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. Any unauthorized review, > use, disclosure or distribution is prohibited. If you are not the intended > recipient, please contact the sender by reply email and destroy all copies > of the original message. This message has been content scanned by the Univa > Mail system. > > > > --------------------------------------------------------------------- > > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
