workflow

[rjmaris]

The web page "Contiribution Guidelines", "Contribution Workflow", describes a "typical" workflow. Then the workflow using forking Zephyr is described.
The formulation suggests that other workflows are possible as well to get locally created and signed-off'ed commits to upstream (e.g. without forking).
Is this true?

[GeorgeCGV]

Hello @rjmaris,

It is typical in a way that this is how it is usually done for GitHub hosted projects where repository ownership is limited to a certain group of people.

Zephyr follows GitHub recommended contribution workflow with some extra rules such as no merges within the pull request (rebase is used to keep PR up to date), certain commit message style, and etc... What exactly people do to stay within contribution guidelines is up to them (i.e., run checks locally or push and await CI, rebase in terminal or GUI and so on...) - therefore, a "typical" workflow is described as an example.

It is not possible to create a pull request until you have a certain set of rights on the repository (create a new branch, merge). It is common for Open-Source projects to use pull request workflow. That solves the problem with giving rights to everyone who wants to contribute. Also, that allows to monitor and control the changes (code review).

[rjmaris]

Thanks for your explanation, I understand this, but I'm not going to fork the repository because of its inherent millionfold waste of server space. Only when github would offer some sort of reverse ssh connection (which is - of course not necessarily permanently staying) to allow my local rapository to also serve the function of the fork on the server side, I'd contribute with code. Am 29.11.2022, 17:44 Uhr, schrieb Georgij Černyšiov ***@***.***>:

…

Hello @rjmaris, It is typical in a way that this is how it is usually done for GitHub hosted projects where repository ownership is limited to a >certain group of people. Zephyr follows GitHub recommended contribution workflow with some extra rules such as no merges within the pull request (rebase is >used to keep PR up to date), certain commit message style, and etc... What exactly people do to stay within contribution guidelines >is up to them (i.e., run checks locally or push and await CI, rebase in terminal or GUI and so on...) - therefore, a "typical" >workflow is described as an example. It is not possible to create a pull request until you have a certain set of rights on the repository (create a new branch, merge). It >is common for Open-Source projects to use pull request workflow. That solves the problem with giving rights to everyone who wants to >contribute. Also, that allows to monitor and control the changes (code review). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[GeorgeCGV]

Most probably GitHub, Bit-Bucket, and Git-Lab employ additional mechanisms to reduce actual disc space requirements.

It is possible to find several discussions on the internet about that topic. For example stack-overflow: explanation of GitHub fork and how they store files). Considering that GitHub is not alone on the market they probably won't share utilized approaches publicly.

Nobody prohibits sending patches as you did with #52556. Contributions are always welcomed. However, that requires someone else to apply the patch on their fork on your behalf and create a pull request. But working that way on a major feature (i.e., #38679) won't be very comfortable as such PRs tend to accumulate discussions and modification cycles.