Thoughts on Git repository and community

by - 00:13

Thomas Paviot announced a git repository that is aimed to accumulate community produced patches in an effort to systematize and ease their production and use. That effort addresses very limited community support from the OCC company side which often begs a question of the company's commitment to Open Source model. That often provokes emotional debates on the forum and I suggest that we put this offline (we can continue in a separate topic though).

I view Thomas' effort as much more constructive than typical claims, so it does deserve recognition, at least in my eyes. I appreciate it like other efforts, including a Wiki site initiated by Fabian Hachenberg, multiple fixes from Denis Barbier and Peter Dolby, numerous projects showcasing and leveraging OCC (pythonOCC by Thomas Paviot and Jelle Feringa, Salome ports by Fotios Sioutis, qtocc by Pete Dolby, etc) and even simple bug reports. As the old saying goes, "it's better to light a candle than to curse the darkness". So every constructive input is more valuable than an emotional claim.

This post is to share some initial thoughts. I suggest that we continue discussing details of Thomas' proposal on some other place, not the org forum. This is just to avoid unnecessary potential sensitive issues. The blog format is likely not too convenient either and another forum (e.g. on wiki) could be preferred.

Repository structure
Let's start with something simple and clear. Arthur Magill has suggested a 3 level structure which I would simplified down to 2:
- One master (mainline / trunk) branch per each OCCT version. The branch would start with pristine version of OCCT (say 6.5.0) and incrementally accumulate fixes. There must be reasonably strict gatekeeping process to maintain it stable. Fixes must be code-reviewed and tested to make this branch.
- Set of experimental branches maintained by individuals, projects, etc. These are sandboxes where volunteers can maintain their own version and which can contain fixes they selectively pick up or produce. No gatekeeping, everything is up to an owner.

Master branch commit process
To make the master branch as stable as possible, some efforts must be applied. I would start with 3 most important:

  • Code completeness. For instance, if you modify the header file then modify both original .cdl file (if applies) and .hxx file. If you modify a .vcproj file for Visual Studio 2008 32 bit then modify files for other flavors of Visual Studio (e.g. 2005, 2010, 32 and 64 bits) and automake files.
  • Testing. Apply reasonable effort to test your modifications.
  • Code review. OCCT is complex and caution must be taken to analyze potential implications (side effects, performance, memory footprint, platform specificities, etc). Ultimately, the best would be to have single decision maker(s) to approve or veto the modification. Participation of OCC team lead engineers would be really helpful. Ideas are welcome.
In the end of the day, the patch should make the official version of OCCT. To make it happen, the community should apply its efforts and due diligence. I could help in code reviewing testing as far as CAD Exchanger allows.

Consolidation of community resources
To avoid unnecessary proliferation of resources and thus confusion on what to use when, I suggest we define the tools and start sticking to them. Ideally, I would love to see all this hosted on but given continuous unwillingness to support that let's host them outside. If we find another single platform we might want to settle down there.
  • Git repository – to ease fixes sharing.
  • Forum. To discuss issues which OCC company does not appreciate on its forum (projects announcement, company policies, etc). More feature-rich forum (e.g. typical phpBB) would help overcome limitations of the ancient org forum.
  • Wiki – to document knowledge, maintain useful links, etc.
  • (?) Bug tracking. Org forum should probably suffice unless there are volunteers to track the bugs along the life cycle.
  • What else ?
Sourceforge could be a good single place but my experience with it was far from smooth, so I gradually gave up. On the contrary, is very nice to work with.

Next steps
Thus, the next steps that I see are:
1. Define a must have list of tools for efficient community functioning. Start with forum, and use this blog until that. Once the forum is defined, continue discussions there.
2. Agree on the git structure and basic policies.
3. Start using it.

I would be thrilled to see OCC folks participating in the discussions and activities as much as they can. I agree with Thomas' statement that we all share same interests.

Thanks !

You May Also Like


  1. Hi Roman, contains a forum system as well. I hadn't used it yet, but used this occasion to open a sub forum for the OCE initiative.

    I'm not sure whether it is powerful enough for the job, but we could give it a try. Even the simple ability to edit a posted messages makes it superior to the org forum ;)

    By the way, a big thanks for your ongoing support of the wiki project! :)

  2. I misspelled the Peter's last name twice. It should have been Dolbey, of course. Peter, my apologies. Thanks to Andrey Betenev for the catch.

  3. This comment has been removed by the author.

  4. Roman,

    Not even my own family get it right - at Xmas, I get cards for Dolby, Daulby, Dalby, Doleby and Pritchard (but they were the previous owners).

    On the MSCV side, I've been starting to build OCC and its dependencies under VC2010 - not got as far as I would have liked, still only up to "freetype". However I am buiding these into the Third Party folder in OCCT. The build has not been particulary clean as these libs have hardcoded lib paths, not relative.

    However, following the guidlines you posted here, it would be painful to support these types of changes to the OCCT build as you'd have to support VC2005 and VC2008, 32 and 64 builds as well - I'm on 32 bit Vista with VC2008 and VC2010 installed and would want to go back to VC2005. To be honest I would have no interest in backwards compatibilty, even though it sounds selfish.

    Interested in thoughts as to how such changes might be supported by the community.

    Pete Daughlbeigh (another possibility)

  5. *should say "would not want to go back"

  6. Hi Pete,
    Thanks for the feedback and sorry for late responses. Glad I did not hurt with wrong last name.
    As for VC2010, what is the point in doing the port as OCC 6.5 already supports it? There are vc10 projects. Am I missing something?

    Your example with hesitation of backport is exactly the point I wanted to make. I fully understand the self interests and lack of resources, but if a patch is incomplete this creates a risk of diverging versions (Version ported on 2010 is better than VS2005). Someone trying to use the version of the unsupported (not backported to) platform will face a unexpected behavior, will ask questions what will require to give explanations and excuses, etc. This can result in greater time than initial diligent port. OCC team can be reluctant to consider incomplete patches or will refuse to integrate leading to maintenance expenses, what again can exceed initial efforts should they have been right.
    If one cannot do all platforms at once, he/she could seek help from other contributors.

    Hope this helps to reflect my viewpoint.


  7. Hi,

    Do you plan to finally clarify/switch to a licence which would be (L)GPL compatible?
    Most linux distros would be very happy to be able to package opencascade and software such as FreeCad which rely on it...
    Previous discussion:


  8. Whom are you asking about the license ?

    If you address to the OCC team, you would better ask on the .org site forum ;-)