[sane-devel] Proposal to disallow direct pushes to the master branch

[Rolf Bensch]

Hi Povilas,

I think using branches depends on the complexity of the changes|fixes.

Document file updates and simple fixes which don't change "my" backend's
functional structure can be committed directly into master.

If new code touches my backend's functional structure, other backends or
sane common functions, it should be recommended to use branches.

If I'm working for myself and if only my backend is affected, I can use
local branches and I only need to push master after local merge. I don't
see any benefit for using a merge request in gitlab for this. Then the
commit messages should explain my changes. And if my branch stays local,
I can use git's versatile functions like rebase.

If other people need to be involved, e.g. for testing, a merge request
in gitlab is appropriated for communication. This is more transparent
than discussing things via the mailing list or even off-list.

If another backend is affected or sane common code, a merge request in
gitlab should be mandatory. And this merge request should be approved by
other(s). This can help to avoid breaking "foreign" code.

Hope this helps.

Cheers,
Rolf


Am 12.10.19 um 01:25 schrieb Povilas Kanapickas:
> Hi,
>
> Currently there are two ways to submit code to the sane-project/backends
> repository: directly pushing to master and creating a merge request on
> GitLab. I'd like to propose we only allow the use of the latter option.
>
> Direct pushes have the risk of accidentally breaking the build or tests.
> Our CI setup tests builds on 5 environments, I doubt that everyone would
> test all configurations that are automatically covered by the CI for
> each code submission. Personally, going through merge requests was
> really worth the 20 seconds that it takes to open one, as numerous
> issues have been found on GitLab CI.
>
> Additionally, merge requests on GitLab always use master branch as the
> first parent. This is important, because it allows various tooling to
> use the `--first-parent` flag to iterate through merges to the master
> branch ignoring the commits. As a result it's possible to e.g. bisect
> some issue picking only the merges on the master branch which makes the
> process much more efficient, as intermediate commits on side branches
> don't even build a lot of the time. As it stands now, it would only take
> a single merge of the current master branch to an old enough commit to
> prevent such tooling working altogether. There have already been several
> occasions of such reverse merges happening, fortunately they used not
> too old commits as the first parent.
>
> What do you think about this?
>
> Regards,
> Povilas
>
>
>