RE: [PATCH 1/2] Documentation about triangular workflow

[ALBERTIN TIMOTHEE p1514771 <timothee.albertin@etu.univ-lyon1.fr>]

Daniel Bensoussan <danielbensoussanbohm@gmail.com> writes:

>> +TRIANGULAR WORKFLOW
>> +-------------------
>> +
>> +Introduction
>> +~~~~~~~~~~~~
>> +
>> +In some projects, contributors cannot push directly to the project but
>> +have to suggest their commits to the maintainer (e.g. pull requests).
>> +For these projects, it's common to use what's called a *triangular
>> +workflow*:
>> + ...
>> +Motivations
>> +~~~~~~~~~~~
>> +
>> +* Allows contributors to work with Git even if they don't have
>> +write access to **UPSTREAM**.
>> +
>> +Indeed, in a centralized workflow, a contributor without write access
>> +could write some code but could not send it by itself.  The contributor
>> +was forced to create a mail which shows the difference between the
>> +new and the old code, and then send it to a maintainer to commit
>> +and push it.  This isn't convenient at all, neither for the
>> +contributor, neither for the maintainer. With the triangular
>> +workflow, the contributors have the write access on **PUBLISH**
>> +so they don't have to pass upon maintainer(s).  And only the
>> +maintainer(s) can push from **PUBLISH** to **UPSTREAM**.
>> +This is called a distributed workflow (See "DISTRIBUTED WORKFLOWS"
>> +above).

>I probably should not be judging if these additions to
>gitworkflows.txt is a good idea in the first place without seeing
>any explanation as to why this patch is here, but I think it misses
>the place where "triangular" sits in a larger picture.

There already have been a discussion about this documentation:
https://public-inbox.org/git/E83A9439-54C8-4925-8EE3-6AEEDD9416F3@grenoble-inp.org/
We forgot to add it to the commit message, it will be in the next
commit message.

>The workflow to contrast against to illustrate the motivation is a
>centralized workflow, where everybody pushes their updates to a
>single place.  It does have problems inherent to its structure
>(e.g. "review before integration" is much harder, if possible), and
>also has its merits (e.g. it is simpler to explain and reason
>about).

>If you want to wean a project off of the centralized model, you'd
>need to use the "distributed workflow".  The workflow to review and
>apply mailed patches in public, and the workflow to have the project
>pull from many publish repositories individual contributor has, are
>two that allows the project to go distributed.  These two are
>complementary choices with pros and cons, and it is not like one is
>an improvement of the other.  Projects like the kernel even uses
>hybrid of the two---the patches are reviewed in public at central
>places (i.e. subsystem mailing lists) in an e-mail form and go
>through iterations getting polished, and the polished results are
>collected by (sub)maintainers and sent upwards, either as a request
>to pull from publish repositories maintained by (sub)maintainers, or
>relayed again in e-mail form (the last mile being e-mail primarily
>serves as a transport vehicle for changes proven to be good, not as
>material to be further reviewed).

>The reason why projects make these choices is because there are pros
>and cons.  A large collection of changes is far easier to integrate
>with one command (i.e. "git pull") and with a need to resolve merge
>conflicts just once, than applying many small changes as e-mailed
>patches, having to resolve many conflicts along the way.  In order
>to ensure quality of the individual changes, however, the changes
>need to be reviewed and polished, and the reality of the life is
>that there are far fewer people who are qualified to adequately
>review and help polishing the changes than those who make changes.
>Asking reviewers to go to different repositories (whose number
>scales with the number of contributors) and leave comments in the
>webforms is much less efficient and more costly for the project
>overall, than asking them to subscribe to relevant mailing lists
>(whose number scales only with the number of areas of interest) and
>conduct reviews there.  Other factors like "offline access" also
>count when considering the two models as "choices".

>As long as the document uses phrases like "forced to", "isn't
>convenient at all", etc., it is clear that it starts from a wrong
>premise, "one is an improvement over the other".

We will take this into account.
We didn't know there were hybrid workflows.

Thank you for your time

Timothée Albertin