Git policy

[Matthieu Brouillard]

Hi group,

as reported in microprofile-fault-tolerance#206 wouldn't it be beneficial to define some common rules on how to handle git history/commits/pr for all microprofile projects.

The microprofile spec projects will never have long living branch and so on, so simple rules with a target to keep the history the more linear than possible would be beneficial in my opinion.

If it is agreed, then I would suggest:

1. to protect the master branch of each project (no rewrite & no direct commit to it)

2. to rebase the PR before integration

- asked to the contributor or done by the integrator

3. to squash commits when relevants

- asked to the contributor or done by the integrator 

4. to define a rule for commits:

- keep merge commit (see explicit commit/contribution) or only fast-forward (keep pure linear history)

 

Then it can be discussed to even go further (disclaimer I am the author of jgitver):

5. remove maven unnecessary pom modification for version management

- use jgitver-maven-plugin

- do not use maven release plugin

Matthieu Brouillard

[Ondro Mihályi]

Hi,

I think that protecting master branch from direct commits makes sense. It's also possible to force at least one approval before a PR is merged to force a review.

As for rebasing/squashing, I'm not sure how this would be applied. I'm not sure that everybody understands well enough how rebasing/squashing works, I would leave it as a guidance but nothing that should be required.

--Ondro

[John D. Ament]

Personally, I feel we need to be able to trust those who are committers on the project to do the right thing.  Eclipse IP policy seems to be based on who authored the commit, so as long as that's in tact I think we're fine any route we take.

What I think we should agree upon is that a committer should not take someone else's pull request, rebase it to change the author, and then push it.

[Matthieu Brouillard]

> ... that a committer should not take someone else's pull request, rebase it to change the author, and then push it.

Agree but if done correctly, maintainers/commiters can "rework" incoming pull request to clean them up. On the commit you should in the end find the author (the one who proposed the change) and the commiter (the one who finally commited to the repo after cleanup).

[Matthieu Brouillard]

Hi,

even if I adhere to John statement saying that "we should trust the committers", protecting the master branch is a kind of safeguard of misuse and is not related to any IP policy.

For rebase/squashing, I think that people who are committers in this project might already know what we are talking about. If not it is just a matter of explaining with small examples what is expected in the end (once the rules are defined). 

Moreover depending on the rules adopted, the new merge/accept PR functionalities of github (image link 1) could ease a bit the work of committers.

Matthieu

[Werner Keil]

Hi,

I would say this is mostly a question of Trunk-based development vs. other concepts and practices like feature branches

Eclipse does not mandate it while some (e.g. Martin Fowler https://www.thoughtworks.com/de/insights/blog/enabling-trunk-based-development-deployment-pipelines) are quite vocal about the benefits of either practice.


Werner