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

[Povilas Kanapickas]

Hi Rolf,

On 10/12/19 6:22 PM, Rolf Bensch wrote:
> 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.

I think it's not completely true that changing code in a certain backend
affects only that backend. The problem is that by default all backends
are built and any compile errors will affect every user of sane
backends. Using merge requests for introducing code to master completely
avoids this possibility.

Regards,
Povilas

> 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
>>
>>
>>