Fri, 03/11/2011 - 09:16
Dear all,
The latest 6.5.0 version was release a few days ago. This new release was expected for a long time by the community. By 'community', I mean people who are not customers of OCC, who didn't pay any fee to the OCC company but just use the product for free or commercial products/projects.
There have been, and there still is, a kind of misunderstanding between the OCC company and the 'community' as previously defined. The community just expects OCC to deliver a good and reliable library, with updates, bugfixes, issue tracking and so on, that is to say provide a XXIth century open source product/project management. On the other side, the OCC first consider their customers request, because the licensing fees from the customers create income. This business model can easily be understood (it's not that original in FOS world), however the community deserves a better consideration from OCC. In my opinion, the OCC company didn't understand yet that the community can create value to the product/project, and that this added value can be converted back to money. This lack of consideration explicitely appears in the 6.5.0 announcement (read http://www.opencascade.org/org/forum/thread_20025/): not even any thank to the community, it's just incredible!
Anyway, the result of this strategy from the OCC company is that the community only benefits today from this poor forum interface to report issues, ask questions, send patches etc. Project plans, roadmaps, issue tracking, source code repository, unit test suite etc. are not publicly available. We (the community) only see the tip of this huge iceberg. Where does this iceberg sail?
After 30 months of work since the 6.3.0 release, the 6.5.0 is out. Expectations were great. Results are, in my opninion, a bit disappointing. Reading the annoucement, I see that "this release introduces about 230 modifications and bug fixes, over previous public minor release 6.3.". 'Minor' release means minor improvements. Well, this is an average of 7.66 bug fixes/minor improvements per month. For your information, from Firefox 4.0 beta 12 to Firefox RC1, 227 bugs were fixed (http://www.mozilla.com/en-US/firefox/4.0/releasenotes/buglist.html) in about two weeks, that is to say an average of 450 bug fixes/month. My conclusion? Although a version was recently released, OCC is not such an active project anymore: fixing 7.66 bugs/month can be achieved by one employee (playing freecell half of his time). Additionnaly, 6.5.0 release seems to introduce regressions, many obvious issues have not been fixed etc. It looks like OCCT is slowly dying, no?
Regarding the latest release, a few fixes are currently being contributed back by the community through this forum (search for OCC650PATCH in this forum). We cannot wait 3 more years (or more?) for the 6.6.0 to be released, and I'm not even sure that any other version will ever be released. Community fixes should be made available to community as soon as possible. Patches are not an easy way to trace modifications to the source code. Some projects were registered on sf.net (http://sourceforge.net/projects/opencascade/, http://sourceforge.net/projects/qtocc/), mostly to share patches, but we should have the complete code somewhere to be able to easily say up to date.
As a consequence, I registered the oce project on github : https://github.com/tpaviot/oce/. oce stands for *o*pencascade *c*ommunity *e*dition. The complete 6.5.0 source code was uploaded (the /ros folder actually). This repository is intended to gather modifs from the community (I'm bored with searching for OCCPATH or OCC650PATCH on this forum), merge OCC services packs from the Salome project etc. Git is a perfect tool to manage such a huge library as OCC.
This project is not a fork. The goal is rather to make the library living between two official releases, ensure a continuity, and setup a tool the OCC team does not want to provide us. There is a risk that this concurrent version diverge from the original one, or that the code is not enough tested and introduce regressions/bugs? Well, no risk, no fun, right?
I strongly encourage Denis Barbier, Pete Dolbey, Roman Lygin and others, who often report issues/bugfixes, to register a github account; then email me to get a write access to the repository.
All the best,
Thomas
Fri, 03/11/2011 - 21:40
Hats Off!
Fri, 03/11/2011 - 22:06
Hi Thomas, Thanks for the effort greatly appreciate your initiative. I would like to get access to oce on github. I shall email you.
Thanks,
Venu
Fri, 03/11/2011 - 22:55
Thomas I agree with your initiative, but commiters should be very carefull for keeping the changes in line with the whole philosophy of OCC so that all the changes could be back ported to future OCC released versions. For example an effort to get rid of the Handle mechanism would be a disaster (at my opinion) and render the "OCE" project non portable to future OCC versions and finally a fork of OCC.The above implies that in case of heavy traffic in future the repository will need some "good" administrative efforts.
A public GIT hub as the one you proposed not only will not create any issues to OCC, but will provide added value for the OCC company since I think it will attract more developers from the IT community to "work" with OCC. Also the OCC team will have access to a centralized OCC patch "database" to apply to their "closed" version (provided that they pass their regression tests).
Finally and not least in order for the repository to be succesfull it must have the wide acceptance of the main patch commiters on this forum and the OCC team (best case scenario would be to have a key contact from within OCC team for advising and mentoring).
My 2 cents...
Fotis
Sat, 03/12/2011 - 08:45
Hi Fotis,
I mostly agree with you.
First of all, as I wrote, my intent is not to *fork* Open Cascade. I mean, in the OS community, forks usually come from members of the dev team who disagree with strategic issues. It's not the case here: the dev tem is somewhere in Russia (as far as I know), programming skills/OCC skills are there. A real and credible fork would have to come from one or more former employee(s) of the OpenCASCADE company. According to me, it would not make any sense to fork OCC.
The first intent of this public repository is to let people use a fixed and working OCC. OCC 6.5.0 is not that perfect, although we waited for 3 years. Although the major skills are in Russia, many people here are very good to hunt and fix bugs. The repository just provides a common and shared place to merge all these contributions. No need to set up a huge and bureaucratic project management workflow: a few people here can be trusted, for instance Roman, Denis, you, and others. I do not have the skill/time to review patches. We'll see in the future if there is a need for some 'good' administrative efforts.
The initial goal is not to develop experimental features and break OCC consistency. However, if someone wants to contribute a new feature and discuss it, git branching is perfect for that. And, who knows, if this contribution proves to bring a major improvement over the official OCC, why shouldn't it be merged to the master branch?
At last, I have a message for OCC dev guys reading this forum: we are not enemies, please consider joining us. We all here share the same interest.
+2 cents,
Thomas
Fri, 03/11/2011 - 23:50
Hello All,
I really appreciate your efforts. I just won't make complains to the OCC team anymore. We know their positions, and they are basically saying "we do business here, and community doesn't return anything". Not true, but let them see what we can do together, and make change their minds! Even with all the limitations, having OCC open source is a great thing.
Since now, what comes from community:
- A wiki
- A cloned repository
- A large collection of patches from Roman, Denis and many others scattered around the forum
- A sourceforge project with previous versions patches.
- Some OSS community projects:
- Qt OCC
- CMake experimental builder
- older (improve cascade...)
- Salome ports
- Others?
- This forum
These OSS projects could be organized and merged in a single repo as "contrib features". Also patches would be useful if presented in a diff/patch format too , and categorized as "experimental, tested, etc...", so one can select witch one to pick, instead of the full "community edition". Could this be done with the wiki?
Also , having a simpler build system would be much better than mantaining 5/6 different project files. In windows, for a community user, it is unlikely to have 4 versions of visual studio installed (which can be normal in a developer machine), so updating a project can be hard.
Cmake is good at this, even with a bit frustrating syntax, but it would simplify so much the management of project files.
The risk of diverging too much is real, but what should we do?
With a complete repo we distribute the effort of having a patched OCC (that everyone has anyway). I suppose that with git you could ignore/revert some commits in your local copy, if you want.
A doubt: will it be easier to integrate the diffs between consecutive OCC versions in the repository, or reapply the patches to every new OCC version? This probably depends on how much the repo changes in the time.
A wiki page could be used to track the latest modifications/improvements done , and a list of common bugs/workarounds.
This is only "loud thinking", just my 2 cents.
I already cloned the repo (readonly by now), but as a subversion user I still have to become productive with git :) WOw, that's much faster than svn!!
Good bye
Thomas (another one, i will change my nick soon :)
Mon, 03/14/2011 - 13:30
Tom, I understand your point that you are not suggesting forking it. But I suggest to the contrary - fork it. I was going back and forth on this one. 3 years waiting for these people to come out of the stone age is foolish IMO. I keep on asking why in the world do we get stuck with a sinking ship. They are in some frozen corner of the globe and probably have a client that totally depended on them(who would blame them - no one uses HANDLE anymore, so even if they want to ditch them they can't) and hence they have little incentive to make any major change since they have to milk their client by making it complicated and buggy - so only their dev guys can "fix it" and they have a cash cow so I can understand why they don't care. There are tons of companies that are and will be willing to support CAD dev work. It only takes one courageous company to change it all. Look at Trolltech -> Qt. I don't have to say more. Things that used to take months are shrinking to take a mere few weeks even days in some cases to develop and polish out a mint app with first time you fire it and ready to go, with multiple platform support and less buggy and all the nice stuff you expect of a self respecting 21st century development. First of all CAD is one last corner that modern development needs to take a good look at. If it were not for competition, we would all be stuck in the 90s. Competition is a good thing and forking it will bring these people from the stone age way of doing things. I mean 3 YEARS is a very very long time and to come up with such a lousy and underwhelming stuff is just unbelievable. But more broadly I am not even caring much about OCC, if you guys are willing why not an entirely new library with clear goal that doesn't need 3 years for a minor release. It can be done and I am sure there are many many good and dedicated commiters. I am still unsure why OCC is in sourceforge, frankly. It is laughable. You can tell by the quality if this forum - it is practically dead forum. In this day and age, you can practically get any question you have on Google if you can't find it in main forums. Try that with opencascade, even Google code give you little to none. This tells you two things - one, this dev tool is dying and two less and less people are interested because it is turning people off as it did for me. In this day and age I can't spend days on a piece of code that should have been done waaaaaaaay easier than it is now. After sorting though all nonsense and fixing their bug I wonder if it would take that much if I just do my own? I am over the fence now and don't think this is a good tool anymore.
Mon, 03/14/2011 - 15:56
Jay,
I'm not an active OCC user so my word won't have much weight, but in general I agree with you.
OCC is going nowhere fast and is not really an open source project in the best sense.
I don't know what is the way forward though.
I'm not interested in OCC anymore. A few years ago I put in quite a lot of time into just getting into grips with
it and a lot of the time was waster in trivialities. Having lurked here I get the same feeling all the time.
What I would be interested in is a true cross platform solid modeling library written in Java.
That would be a project I would be interested in using and contributing to.
I gave C++ up years ago (and I was and still am pretty dab had with it) as just too difficult and
slow (to develop in) in real world and my recent relapse into it in the context Qt (which by itself is great)
did not change anything. It is just chain and ball for both development and deployment.
So if a Java based project somehow emerges count me in but fork or no fork OCC is not in my starts.
My 1 snt worth.
br Kusti
Mon, 03/14/2011 - 16:18
Hi Jay,
You might be interested in the jcae project: https://github.com/jeromerobert/jCAE (jCAE is 'java Computer Aided Engineering', based on OCCT).
Regards,
Thomas
Mon, 03/14/2011 - 16:34
Dear Jay,
Everything is not that bad in the OCC world. There are many things to improve indeed, but OCCT is still, in my opinion, the best FOS CAD library currently available, and the project is not dead yet. It encounters serious difficulties? As a famous english guy once said, "the optimist sees the opportunity in every difficulty". Let's keep optimistic!
The question is not, as you write, "to fork or not to fork" (as could have wrote another famous english guy). The issue is rather: can we gather our forces and make something by our own? If the answer is 'yes', then maybe one day the question of forking will be asked. If the answer is 'no', I'm afraid that OCCT will only survive untill the Salome-Project is finished.
You say it's not a "good tool anymore". Join us and let's make it better!
Thomas
Mon, 03/14/2011 - 17:02
>>> There are many things to improve indeed, but OCCT is still, in my opinion, the best FOS CAD library currently available
Hear hear; OCC represents a decade[s] of work and one that will not be replicated.
So, the wise and practical thing to do is to make the best of it.
The politics of software is a do-mocracy; if you have an itch to scratch, than do something about it.
>>>The issue is rather: can we gather our forces and make something by our own?
I hope so, one thing is for sure; this is _the_ moment to do so!
-jelle
Sat, 03/12/2011 - 16:17
Hello Thomas,
This is an excellent idea - a place to centralize various bug fixes and modifications will really help build a community. And a big thank you to you, Dennis, Roman and others for all your hard work, and of course to the OCC team as well - as Thomas rightly points out, we're all on the same side here.
I would like to see several branches in the git repo. For the basic build, I think three branches would be useful:
1) Pristine source, as delivered by OCC.
2) OCE (semi)stable - commits that are known to work, after some level of testing.
3) Unstable, bleeding edge - where new commits are first made.
1 would be read-only. We would have to decide what criteria a change has to satisfy to step from 3 to 2. I have in mind that most of us would use 2, with reasonable confidence it will work as expected, while those of you actively fixing issues would work on 3. Does this sound sensible? Maybe we should write a procedure for testing on various platforms, as a check for moving from 3 to 2. That would be something those of us less deep into the code could usefully contribute.
You could also add branches for specific projects, such as CMake. As these are proven useful and stable, they could then be folded back into 3 then 2, following the normal path.
I agree with Fotis that major changes, such as removal of the Handle mechanism, should be avoided - but I don't think that is what you are proposing anyway. Of course, new features could be added, so long as they don't break backward compatibility (perhaps the build system should include a switch to the effect of --disable-oce, to disable any community added extensions?).
Thanks again all for all your efforts,
Arthur
Sun, 03/13/2011 - 12:51
Dear all,
I created a the 'oce-dev' Google Group: let's discuss these issues on http://groups.google.com/group/oce-dev/ .
ml address: oce-dev@googlegroups.com
Thomas
Sun, 03/13/2011 - 13:30
excellent idea!
Sun, 03/13/2011 - 16:15
Just thinking, why have so many places to collate ideas? sourceforge with atleast 2 groups working on OCC related projects/code paths etc, then your idea of oce, which makes sense but now a discussion group for just oce related discussion? why not discuss in the oce project in github itself? the information gets dispersed if we have too many projects and one needs to see atleast two places to get the complete picture. Just my thoughts.
Sun, 03/13/2011 - 16:27
Hi Venugopal,
That's a good point. However, git makes it *significantly* easier to work on a number of branches. So, I think OCE potentially could integrate the various forks floating around. Its something to be debated; I share your concern.
Sun, 03/13/2011 - 17:38
Hi Venu,
The deal is usually 'one project, one repository, one mailing list'. Up to now, there are many different and separated projects (opencascade-cmake and qtocc adress 2 different issues). Let's say OCE is an attempt to go beyond these small parts.
This forum is not the right place to discuss the OCE project, that's why an another ml is necessary (discussing the project inside git itself is not a good way to exchange information and get archived by the search engines, however code can be reviewed/commented from github).
Regards,
Thomas
Sun, 03/13/2011 - 18:06
"Let's say OCE is an attempt to go beyond these small parts"
Which is much needed indeed.
I'm quite confident that a git repository significantly [-> cheap / easy branching + merging] aids in this process.
The OCC community at large could possible become more cohesive if we find ways to keep focussed on the bigger picture.
Mon, 03/14/2011 - 04:43
Understood Thomas. Yeah now I have registered in both the groups.
Thanks,
Venu
Mon, 03/14/2011 - 23:39
I'd be very happy to have just one source for community patches for OCCT 6.5.0. I will apply for github accounts once I've built a new development environment under VC2010 for OCC, Qt and other libs - currently working on freetype.
It was never my intention to maintain anything like a fork of OCCT 6.3, the svn respository just contained a set of OCCT changes that I wanted to make qtocc work the way I "liked" (i.e. gradient background etc).
I have been quite critical of the way that OpenCASCADE S.A. have treated the community recently, with failed commitments to their published roadmaps. However on the positive site, I have seen a number of patches marked QTOCC_PATCH in the source codes, so at least some of the work (i.e. the community) have made available via svn, zip distros and forum posts have been taken in to the core code. This at least gives me some hope that OCCT is not dead from a open source perpective.
I've been working away from home a lot over the last 12 months, so haven't been very active here (don't want to carry both my work and home laptops to Sweden every week). Hopefully, I will be able to contribute a bit more soon.
Pete
Sun, 03/13/2011 - 21:29
> Why not discuss in the oce project in github itself?
Because github does not provide discussion lists ;-)
Mon, 03/14/2011 - 04:42
That's fair enough :), usually repositories do have don't they? anyways, thanks for pointing that out.
Sun, 03/13/2011 - 12:18
+1.
Tue, 03/22/2011 - 00:24
After some thinking over Thomas' proposal I have posted my reflections here - http://opencascade.blogspot.com/2011/03/thoughts-on-git-repository-and.html. We might want to follow up the discussion there until a better place is found. I'll try to be responsive but don't promise :-|
Tue, 03/22/2011 - 13:04
Hi,
at
http://opencascade.wikidot.com
we have slowly begun in the last months to build a wiki for knowledge exchange related to Open CASCADE. It's still very brief.
The wikidot platform includes a forum system as well. I created a sub forum for the OCE project
http://opencascade.wikidot.com/forum/c-237903/general
The forum is propably not ideal for the job, but it's at least more technically advanced than this system. So it might help at least as a starting point to heaten up the discussion about the OCE initiative.
Tue, 03/22/2011 - 13:46
A google group was created a couple of weeks ago, to discuss the oce project. It is called 'oce-dev' and is available at: http://groups.google.com/group/oce-dev. This group already hosts discussions between member of the oce project ('member' meaning all of us having a write access to the git repository).
This GoogleGroup is a good compromise between a ml and a forum, with powerful search and archiving features. Everyone here is welcome to join this group: the official OCC forum does not mirror all topics discussed on oce-dev.
Thomas
Tue, 03/22/2011 - 16:14
Hi all,
Excellent initiative! I bet OCC with good community support can really make a huge step forward... Wish I had the skills to do some patching too
Cheers
Yorik
Tue, 03/22/2011 - 17:23
You're welcome to contribute, Yorik. Anyone can get a write access to the github repository, you just have to request one.
The current workflow is:
- anyone can create development branches, and commit anything to these branches (there are currently 7 dev branches)
- a dev branch is merged into the master branch only if it has been tested and if other developers agree with this merge (the merge request being discussed on oce-dev).
The oce project is widely open and is based upon mutual trust. Have fun on experimental branches, do not merge to master unless you have the agreement from other devs.
Thomas