Use of branches and pull requests

[ralfhandl]

Once the repo is public

• [x] protect master branch, require pull requests for every change
• [ ] require one positive review per PR
• [ ] merge trivial changes with one positive review
• [ ] non-trivial or controversial changes need approval in the weekly TC call
• [x] only allow squash-merge to keep revision history clean
• [x] auto-delete branches in this repo on PR merge
• [ ] require working in forks and disallow branches in this repo

[ralfhandl]

I think two approvals should be sufficient.

Typically we have three people involved: one to apply the issue, one to move, and one to second.

That would translate to the PR owner and two reviewers. Objections can be raised by requiring changes to the PR, or by opening a follow-up issue/PR in case the original PR gets reviewed and merged too quickly for the fourth person to review and request changes.

Objective is to ease async/offline work and save the TC meetings for planning and general direction.

[wtrocki]

I do not think that current restrictions work for the repo. We see many PRs with small changes and not meaningfull messages being merged on the other hand some large chunks of work that have proper commit structure are merged into one. I think we should enable rebase option.

I would like to create less PRs but focus more on work and have proper git messages going forward - having rebase will work for Dev team assuming that the docs changes will not miss use it etc.

I'm used to long running PRs with proper quality etc. but current workflow forces me to push changes with poor quality or micro PRs with little meaning

[ralfhandl]

@wtrocki I’ve enabled rebase option.

Could you please explain its benefits?

I typically have very small commits:

• add a test that fails, commit
• change code to pass test, commit
• refactor code, commit

With dozens of iterations for a noticeable feature.

Do we really want to have all of these little commits in the master branch? Squash-merging complete features is more appealing to me.

[wtrocki]

I will never commit them this way. Example above would be just single commit. I never use github merge button for code.

What I mean now is that I can do couple commits in PR like

Docs: Update RSDL spec to include container Feat: Container for cli transformation Feat: Add Action support Feat: Validation for container and unit tests

For the last weeks thouse would end in 4 separate PRs that were really half backed and not properly tested. So usually all those will be squashed into one. I will think as squash all all the time but for code use

fix: feat: chore: Docs: BREAKING:

if we keep the commits nice for the code it can be used to generate miningful changelong with breaking changes.

Most of the open source project adapt this approach so I'm not inventing anything.

[wtrocki]

I just want to minimize noise by creating so much PRs. Push some really good quality changes and produce meaningful changesets. Thx

[wtrocki]

Also since things starting to mature in vision we can start enforcing some quality standards for website and code to make things more solid first.

We were rushing to get something out the door that people can experience - now it is time to put out some safety net. This is important especially when other members will join and Community. Especially community might bring low quality changes and without proper infrastructure and rules things will go bad quickly