Mon, 12/12/2011 - 18:41
Dear Contributors,
The contribution workflow is still being developed within the scope of this project. Meanwhile, we have significantly improved our previous integration process, especially through the legal frame we propose, which is to sign a Contributor License Agreement (CLA).
We encourage all of you who have contributed or are going to contribute to OCCT development to sign the CLA. This is the first mandatory step for your contributions to be integrated into OCCT. The CLA and the instructions for signing it are presented in the Get Involved section of this website.
This message is to explain this current integration process, and possibly to start a discussion gathering your comments and suggestions. Please note that we do not consider this process as a final one, it is only for the transitional period until a complete set of tools is set up and a more open process gets established. Please join the discussion on the tools we are going to provide to achieve a better process, in a separate thread.
Our integration process is built around the MantisBT issue tracking system, now available publicly at http://tracker.dev.opencascade.org. This system contains all the issues we handled on OCCT for the past 10 years, therefore those of you who are interested in the destiny of the bugs registered after they had been reported on the OCCT user’s Forum, can try to find those issues there by their ID's. Note that at the moment only the issues originated from the open source community are visible publicly; the issues originated from our customers are kept confidential (they can be opened only if we get an explicit permission from the customer to do so).
Each change made to OCCT must be recorded as an issue in the tracker and needs to pass through a standard life cycle: submission → assignment → resolution → code review → testing → integration.
The details on the issue life cycle are described in the document Contribution Workflow. Here is a short description of the process, where you are assumed to be a contributor providing some fix or improvement into OCCT.
- You need to be registered on the portal and have the CLA signed and approved (your role will become a “Contributor” then) in order for your contribution to be considered.
- You create an issue for the contribution in the tracker. It is important to provide a good subject reflecting the nature of the change, define appropriate parameters (severity, category, etc.), and give a detailed description for the change including (when possible) steps to reproduce the problem (or test the improvement). The issue gets status New and is assigned to the person responsible for the OCCT component indicated in the field вЂCategory’.
- You provide the sources for the change and switch the issue to Resolved. Currently the recommended way of providing sources is a patch (diff) file, along with indication of OCCT version for which the patch has been made. Alternative ways such as an archive of changed files could be Ok as well. (In the near future we are going to set up a public version control system, and source code changes will be managed as branches.)
- The code is reviewed by our expert; if any serious issue is found, the issue including the comments on encountered problems is assigned back to you, for you to provide a corrected version or additional information as requested.
- As soon as the review is completed successfully, the change is tested by OCC certification team on non-regression tests database. At this step, you can be requested to provide more information on how to test your change. If the tests fail, we may either reassign the issue back to you to solve the problem, or fix the problem by efforts of our own team, depending on the case.
- When the tests are Ok, the bug is switched to Tested, then to Verified (upon integration to the main branch of the version control system), and finally to Closed (when a corresponding certified OCCT version is released). The issue will be returned to you so you can check whether it is integrated well, and then your name can be seen in the Change Log or the Roadmap in the tracker.
Please feel free to ask questions and propose your ideas if you see that something can be improved.
Andrey
Thu, 02/02/2012 - 16:06
Dear Sergey,
my status was changed yesterday from 'reporter' to 'updater'. That confused me a little bit and so I would have some questions.
1. I cannot report issues anymore. Why? (probably related to question 2)
2. I cannot set [Myself] as reporter when filtering issues. Why?
3. I see I can change the status of my reported issues to either 'feedback' or 'resolved'
3a. What does 'feedback' exactly mean?
3b. I see the reported issues were already assigned. Am I still supposed to upload a diff/source file (as stated above in your post)? At the moment I have updated the status of some issues I posted/uploaded some code suggestions for as 'resolved'.
Thank you very much.
Pawel
Thu, 02/02/2012 - 18:58
Hello Pawel,
First of all, thank you for your effort in registering issues in Mantis -- this will definitely help OCCT to become better!
You are right: we are doing some changes in the bug tracker, and in particular we have made one more project, "Open CASCADE", publicly available. This is done in order to make community more aware of what issues have been registered within our team and how they are processed. Sorry for having not announced this immediately, we have been doing some tests there to tune the access rights properly.
Naturally this change was not intended to reduce your access rights: you should still have possibility to report and handle the issues in the Community project. Please check this now (we have just made last adjustments): try to switch the current project shown in Mantis to "Community" using combo-box in the right-upper corner of the window. Then you shall see the option "Report Issue" as before. You shall also have [MySelf] option now available for filtering reporter when you look at the Community project.
On point 3:
(a) Status "feedback" is used to request additional information or ask for an action that is not within usual workflow.
(b) The issues that have been already assigned are those that contain sufficient information for us to process them. For the other issues you are welcome to submit also a patch file if you have it. Switching status to resolved is Ok for the issues where you provided a solution -- this way they will be processed faster.
Please note that while we have started processing your reports on problems found by cppcheck and similar tools, we still need to have CLA signed on your side for us to be able to accept your direct contributions made as patches. Thus I kindly advise you to consider the new version of the CLA announced yesterday.
Hope my answer helps to fix the point.
Please feel free to post your questions or suggestions if you see something that can be improved.
Andrey
Thu, 02/02/2012 - 21:31
Hello Andrey,
thanks again for your comments. I'm really very happy this development platform works and is actively supported by the OCCT team! I hope a public source repository will be available soon!
Let me make a short summary on what I have observed while testing Mantis just a while before.
Yes, I can see both projects and got the 'reporter' status back in case of the 'Community' project (I can report again). For the 'Open CASCADE' project I still have the updater status - I'm not sure if it was your intention.
As mentioned on the OCCT forum, I'm still waiting until the CLA is processed by the legal department of my customer who owns the copyright...
Pawel
Thu, 02/16/2012 - 18:25
Hello Pawel,
Welcome to the development team -- your access level in Mantis tracker has been elevated to 'developer'. Thank you for joining us!
You still have different status 'updater' in project 'Open CASCADE'; this is made to prevent you from occasional reporting issues through this project, while reserving possibility for you to participate in discussion of the issues through notes.
We have made some additional changes in configuration of Mantis to fine-tune access rights and workflow transitions. In particular, filtering of issues by reporter and reporting new issues should work even when you have current view set to 'All Projects' (points 1 and 2 in your message above).
Please let us know if you notice some misbehavior or have an idea how to improve.
Andrey
Thu, 02/16/2012 - 18:47
Hello all,
Please have a look at the updated Mantis page: we have added a graphic chart of the typical life cycle of the issue at the top, to help all involved people to understand better how the process is organized. Please feel free to comment on this.
Andrey
Thu, 02/16/2012 - 19:08
Thanks, this is an excellent idea.
The 2 rightmost boxes may be confusing, community members have no access to a fixed version. Hopefully this will happen soon ;-)
IMO the Closed/Released transition must be performed by bugmaster, you cannot rely on reporters for changing bug state.
The feedback state is very interesting when dealing with community reports, often you end up asking for more details and reporters do not reply in a timely manner.
Thu, 02/16/2012 - 20:04
Hello Denis,
Thank you for commenting! Sure the right-most boxes are relevant to integration phase and they will have more sense for community when Git is available publicly.
The idea behind assigning the issue in Verified (i.e. integrated) state to the Reporter is to suggest him an option to check the fix as-integrated, in the environment where the issue has emerged. Naturally this makes sense only when repository is available to the Reporter. The switch to Closed is made by Bugmaster, unless Reporter complains about the fix before release.
The feedback state is not put on the picture just to overload it. For the same reason other transitions such as possible rejection of Verified issue are not shown. You can click on the chart to open the workflow document which contains more complete graph.
Andrey
Mon, 11/21/2022 - 19:32
Everything is very clear, thank you for the useful information.
Mon, 08/26/2013 - 13:59
Dear Andrey,
I'm a newbie in OpenCASCADE collaborative development. Due to my job I've fixed the numerous issues in the meshing algorithm (based on version 6.6.0) and I would like to share my results with the community. As my test base I also used the model attached in the bug 0023105.
In the same time I can see, that some issues were fixed already. Therefore I would like somebody to guide me through the best code submitting opportunities: do I need to create an issue to submit code? Should I create an issue for each fix or a single issue with a list of fixes is fine?
The issues I fixed:
1) Wrong radius calculation in BRepMesh_CircleTool
2) fillBndBox in BRepMesh_Delaun fixed
3) FrontierAdjust algorithm modified in order to avoid border intersecions
4) CleanupPolygon algorithm reimplemented in order to avoid unnecessary triangles deletions
5) The deletion of "free" frontier edges should cause errors or warnings
6) For better and faster results the outer wire should be triangulated first
7) ProgressIndicator added for the mesher in order to have an ability to cancel meshing
Thank you!
Regards,
Dima
Mon, 08/26/2013 - 14:39
Hello Dima,
You are welcome with your contributions, and I am glad to give you first guidelines on our development process.
First, please notice that for integrating your contributions to official version of OCCT we need you to sign a CLA (Copyright License Agreement) document -- a legal paper which gives us (OCC) a formal permission to include and use your code in OCCT. In your case, I guess you likely will have to sign CLA on behalf of your company. Please find additional details here.
As soon as you provide us signed CLA, you will get access to OCCT Git repository (you will only need to submit your SSH key though your account page on this portal).
> do I need to create an issue to submit code?
Yes it is necessary to register an issue in the tracker for each contribution, it will be used to track all the steps of its processing. Then you commit your changes to Git branch with name starting with "CR" followed by issue ID, and switch the issue to Resolved status for it to be further processed (reviewed, tested).
> Should I create an issue for each fix or a single issue with a list of fixes is fine?
It is better to create separate issue for each fix / change (this would facilitate analysis of possible regressions if found in testing), however it is also acceptable to create single issue for all.
Hope this helps.
Please feel free to ask if you have other questions.
Andrey
Mon, 08/02/2021 - 19:45
Do I need to provide the code fix and testing code myself if I have reported an issue? This is to get clarity regarding point number 3 in your original post "You provide the sources for the change and switch the issue to Resolved......."