FreeCAD Contribution Process

[paddle]

The project Administrators will manage the set of project Maintainers. They SHALL maintain a sufficiently large pool of Maintainers to ensure their succession and permit timely review of contributions

This is all well and great, let's do something then. Because right now my PR are sitting idle seemingly forever. So either add more maintainers, though I opened a topic at that very subject and got exactly 0 reply : https://forum.freecadweb.org/viewtopic.php?f=10&t=72979
Or it should be defined what is 'timely' exactly and what process is taken to ensure that it is done.

Gui: Add option to show workbench selector in menu bar #7679
Simple +-100 line commit adding a setting. Up for the grab !
https://github.com/FreeCAD/FreeCAD/pull/7679

Sketcher: Constraint widget rework
Abdullah has it on his roadmap, but Abdullah roadmap is sooooo full with jnxd and my stuff + all the other that he has that it would really help if someone could handle a look at this one. This is not sketcher specific PR, it's a UI PR. Lot of lines as it moved the big filter around. Though the code itself is pretty easy as only things moved around. This UI change has been approved by Abdullah 'visually' and is consistent with the Element widget rework that he merged last week.
https://github.com/FreeCAD/FreeCAD/pull/7566

Sketcher: Task panel, 'solver message' and 'Edit controls' rework.
Simple +- 100 line commit, with 95% endorsement. Same it's on Abdullah roadmap but for the same reason, please someone handle it. Openbrain already review it.
https://github.com/FreeCAD/FreeCAD/pull/7581


Sketcher: Gui: force-hide toolbars + Split sketcher toolbar
Chennes has this one on his roadmap
https://github.com/FreeCAD/FreeCAD/pull/7655

[Roy_043]

A PR SHOULD be a minimal and accurate answer to exactly one identified and agreed-on problem.

So for each and every PR I submit there has to be a prior approved GH issue? Going from a forum topic directly to a PR is no longer allowed? Even for an obvious bug a GH issue must first be created?

[user1234]

About the MS stuff, I get what you are saying and I did advocate for removing the rule of having a platform account, but we also have to understand that the process has to be practical for devs, you can always sing up on github with a fake email.

It is not about fake accounts, never was, it is about the periphery around the repository. While the repositories (FreeCAD have more then one) are free and can be easy moved, it is not the case about issues and PRs. When they want, they can switch it off imminently (sure they will not do that), or make some unpopular desicions (subliminal nudging it more to their MS environment, like today pupil, or former sourceforge fails), which make a movement necessary. And often when they go in that direction, the often make phony hurdle to move it, or at least it is not lossless. This is why i do not trust github/M$, or better said, all big tech companies. You are not the owner of you own stuff, this periphery is an subliminal indirectly vendor lock in.

Greetings
user1234

[adrianinsaval]

I understand and I agree with some of your concerns and with the whole auto-pilot debacle (and in general all it's history) it is clear that MS is not trustworthy. Personally I would prefer if it was on gitlab or even better a self hosted gitlab/gitea instance but the reality is that github is the most popular and gets the most participation and exposure, and self-hosting is likely inviable right now (maybe in the future when FPA has more resources).
I'll note that AFAIK it is perfectly possible to fully migrate the github issues to other platforms, IIRC this was also a consideration when the decision was made to use their issue tracker. Where they are truly hooking people to their platform is with the CI service, it's pretty damn convenient and probably would require some manual work to migrate to other platforms.
Either way, the process is in reality independent of github, say we move to gitlab, we just change the one mention of github to gitlab and all references to PR to MR and it's good to go, so this is a separate discussion (that I don't mind having!)

[wandererfan]

Because right now my PR are sitting idle seemingly forever.

issue #7695

[wmayer]

7. If a PR contains multiple commits, each commit MUST compile cleanly when merged with all previous commits of the same PR. Each commit SHOULD add value to the history of the project. Checkpoint commits SHOULD be squashed.
9. A PR MUST compile cleanly and pass project self-tests on all target Platforms.

These are nice rules but in practice hardly always to achieve. A contributor usually works on one platform (Windows, Linux or macOS) and doesn't have several platforms to test a PR. Since there are differences between the compilers for each platform it can happen that actually valid C++ code compiles fine with one compiler but fails for other compilers. The reason therefore might be:

1. The compiler on one platform doesn't support yet a C++ feature that is supported by the compiler on the other platform
2. The compiler has a bug

Furthermore, a contributor has a certain set of libraries and depending on the versions the PR may fail with another set of library versions.

What I miss is a rule that a contributor who fixes a bug should also write a unit test to demonstrate what the problem was and that it's really fixed now. Otherwise it can happen that an already fixed bug will re-appear.

About forcing people to use GH I consider it a problem too because there are some people in the FreeCAD forum who will never ever use GH. At least for contributions it should also be allowed to make a branch on another coding platform (e.g. Gitlab) and then create a new topic in the section Pull Requests. The question then is the way how to merge the external PR. One possibility is that a maintainer creates a branch on his FreeCAD fork and opens a PR of that or the maintainer can checkout the external PR locally, merge it and push it.

But for reporting bugs I don't see an alternative than using GH. Issues can additionally be discussed on the forum but a ticket must be created on GH.

IMO it's not necessary that a contributor of a PR must have created a ticket. IMO it suffices that the issue is properly described in the PR.

[Roy_043]

But for reporting bugs I don't see an alternative than using GH. Issues can additionally be discussed on the forum but a ticket must be created on GH.

IMO it's not necessary that a contributor of a PR must have created a ticket. IMO it suffices that the issue is properly described in the PR.

This is contradictory, please clarify. When fixing an 'obvious' bug submitting a PR should there be a previous GH issue or not?

[adrianinsaval]

what he meant is that you can't create an issue somewhere else, that is you can't go and do a bug report on gitlab. PR without creating an issue is fine.

At least for contributions it should also be allowed to make a branch on another coding platform (e.g. Gitlab) and then create a new topic in the section Pull Requests. The question then is the way how to merge the external PR. One possibility is that a maintainer creates a branch on his FreeCAD fork and opens a PR of that or the maintainer can checkout the external PR locally, merge it and push it.

don't we have github to gitlab sync enabled? If I'm not mistaken it's possible to merge something on gitlab and it'll auto sync with github, so one possible alternative is to allow creating merge request on gitlab and merging there. If not I think there is also a way of syncing PR/MR so a bot could make a PR on github when a MR is created on gitlab. For those who don't want to even use gitlab I guess they'll have to get in touch with someone who would be willing to look at their stuff in whatever platform they use.

[wmayer]

This is contradictory, please clarify.

No, it's not! A PR is not a ticket.

For a PR it's technically not needed that it must be published on GH. It can also be published on GL or any other code hosting platform. Theoretically even a patch file would work but because of line endings it's a bit cumbersome.

Btw, on GH there is even a workflow to merge a PR via patch file:

Code: Select all

git checkout -b mylocalbranch master
curl -L https://github.com/FreeCAD/FreeCAD/pull/<PR-name>.patch | git am -3

A ticket describes a bug or a feature and having it only on the forum doesn't make sense because nobody will remember it after a while. Thus, it must be created on a dedicated platform such as GH.

When fixing an 'obvious' bug submitting a PR should there be a previous GH issue or not?

IMO, this shouldn't be mandatory.

[Roy_043]

Nobody is infallible. What is the procedure if a PR is wrongly rejected?