Mon, 07/08/2024 - 10:49
Hello dear OCCT collaboration forum community,
We are thrilled to announce that the OCCT GitHub repository is now open for Pull Request (PR) integration. For those eager to collaborate with us on GitHub, we have prepared the initial version of our GitHub collaboration workflow. Please note, the current workflow is subject to change, and any updates will be communicated through new forum articles. Documentation will be updated once the working process is fully determined and described.
OCCT GitHub Workflow (V1):
Licensing: OCCT is available under the LGPL 2.1 license. To integrate any of your changes into our repositories, collaborators need to sign the Contributor License Agreement (CLA). Details on how to sign and submit the CLA are available on the following page Get Involded].
Bug Tracking: All OCCT commits must be associated with a specific bug ticket in our bug tracker. We recommend creating a profile in the bug tracker BugTracker] when you sign the CLA. This is required for integrating your contributions into the OCCT repository. GitHub users can describe their issue in a special PR, and the OCCT team will create a connected ticket with your provided information and update your PR with the correct title.
Forking: PRs to the OCCT repository are accepted only from external forks. Please create your own fork and work within your repository during the development process.
PR Submission: Once you have completed your code updates and prepared the final fix, please submit a PR to the OpenCascade OCCT repository using the following templates:
If your PR has a connected bug ticket in our bug tracker:
- PR Name Template:
<ticket number>: <Category(es)> - <Summary description> - PR Description: Should contain a summary of your changes in a clear and concise manner.
- Example:
0032750: Visualization, AIS_Manipulator - selection of moved object is broken Completed the stop transform action when dragging manipulator with mouse. Added context redisplay for update of interactive object sensitive areas. Added test.- PR Name Template:
If your PR does not have a bug ticket:
- PR Name Template:
<Category(es)> - <Summary description> - PR Description: Should include the following details:
- Steps to reproduce the issue.
- Any necessary files related to the bug.
- Version of OCCT when the bug was found.
- Type of the issue (minor, major, crash, documentation).
- Platform where the issue was found or fixed.
- PR Name Template:
The information about the fix itself should be presented in one of your commits. The git commit message should match the PR template for cases when you already have a created bug ticket.
Available categories: Data Exchange, Visualization, Coding, Documentation, DRAW, Testing, Configuration, Application Framework, Foundation Classes, Mesh, Modeling Algorithms, Modeling Data, Samples, Shape Healing.
CLA Number: Please include your CLA number in the GitHub note. This number is provided in an email from us that confirms your CLA signing request. This step is required only once per account.
Branching: PRs to the master branch are not accepted. After verifying your CLA, the OCCT team will update the PR base branch to an IR-n branch. The IR-n branch is used to collect a sequence of git commits for integration into the master branch, helping us validate and test issues collectively to avoid conflicts.
Testing: The OCCT team will initiate the testing process and share the results with you. If there are any regressions, we will ask you to address them. If testing on your end is not possible, the OCCT team will take over to fix the regressions. In such cases, the issue will be queued for the next available developer.
Code Review: The OCCT team will conduct a code review, sharing any remarks and suggestions to ensure a collaborative integration process. Any changes during the code review should be made by the PR submitter.
Approval and Merging: Upon successful testing, an OCCT team member will approve your PR, and the bugmaster will merge your PR into the IR-n branch.
IR-n Branch Lifecycle: The IR-n branch will exist for a period during the internal development cycle. You will be notified when your changes have been merged with the master branch.
We are committed to simplifying the collaboration experience. Your suggestions and feedback are always welcome.
Best regards, OCCT3d development team.
Tue, 07/09/2024 - 10:33
These no-reply emails with cryptic numbers don't look nice to me...
Tue, 07/09/2024 - 10:58
Hello, I will check the possible ways to change that result. Additionally for some reason the name was used as a profile name in my case.
Yes, that result was not planned. If you know possible ways to updated GitHub setting to do something with that, please let me know.
Best regards, Dmitrii.
Tue, 07/09/2024 - 11:11
As I can see it is a result of merging from the Web-Interface. Original email (before merging) was correct. Next Integration Request and closest PR will be merged via CL.
Integration request to master by dpasukhi · Pull Request #27 · Open-Cascade-SAS/OCCT (github.com)
That looks better. We will keep the old committing way. Unfortunately, GitHub have no enough flexibility via web.
Best regards, Dmitrii.
Tue, 07/09/2024 - 13:52
Yeah, web-interface tools processing MR (like GitLab or GitHub) tend to take user profile settings when they need to modify commits (e.g. squashing multiple commits. or editing description, or just by rebasing the patch). I don't think that command-line interface to MR in these systems will provide more control over this.
Tue, 07/09/2024 - 14:00
CL in current context is not a CL from GitHub ("gh"). GH has the same functionality as a web interface. I was talking about just terminal git commands. As I can see it can be a solution(from my fast checks and some GitHub discussions). We continue to investigate. But indeed, that limitation is not expected.
Best regards, Dmitrii.
Mon, 07/15/2024 - 18:44
Thank you for your help. Even without updates the ruleset, push to master if PR is created will work perfectly and not rewrite commits. (Even if master is read only, but in case of existed PR merge is possible just by normal git terminal).
Best regards, Dmitrii.
Wed, 09/25/2024 - 16:54
A new extension for collaboration - "Issues" based on GitHub. You are free to share your problems in GitHub without external bug systems.
The link: Issues · Open-Cascade-SAS/OCCT (github.com)
Best regards, OCCT3D Team.
Mon, 10/21/2024 - 22:01
What is the intended software license of the samples in the "OCCT" repository?
- The FAQ item "Is it possible to reuse the samples that come with OCCT installation in my own products?" on your site (https://dev.opencascade.org/resources/faq) seems to indicate that they can be reused freely,
- the phrasing of the description in "samples/qt/Common/src/OcctWindow.h" make it sound like you want people to use the file almost as is, as a utility class (and other files would be nice to copy from), and
- the "OCCT-samples-csharp" repository appear to be under a MIT license (which is pretty free).
But the OCCT repository seem to have a LGPL license (which is not that free) and I do not seem to be able to find an explicit exception for the samples folder (only for the header files that are par of the library). It would be nice if you could add one if something other than LGPL is intended.
Tue, 10/22/2024 - 10:07
Anders wrote:
Formulating a proper license terms for code samples is pretty tricky. Obviously, it doesn't make sense prohibiting reuse of code of a sample - this is the very purpose of such samples, after all!
But puting them simply in a public domain doesn't fit well too. You may find the following phrase in some OCCT samples:
Take a look at this notice in the message:
The header indicates that this file is part of OCCT samples, and asks to keep this message in it!
I would say that intention of this message is NOT to prevent reusage of code in the sample, but to prevent redistribution of the sample with removed copyright.
E.g., if you made a trivial copy of the sample or made some minor modifications to it - please redistribute it under the same license conditions as the original sample.
But if you write your own application, which reuses some portions of the sample, so that these reused portions become negligable part of the whole product - then this product doesn't need to have the same information as in sample file.
Practically speaking, the portions of reusable code are duplicated by many OCCT samples and in documentation, and writing the new application completely reusing the whole sample is not a good idea, as samples are intended to provide short introduction to OCCT functionality, usually over-simplified (or in opposite - overcomplicated to do simple things for verbosity).
This is NOT exactly what is written in samples, but rather my personal understanding of the intentions. It might be helpful to make a better description in documention related to the samples to avoid confusion and maybe even mark them with a simple license - just to make things simpler.