Daniel Bensoussan <danielbensoussanbohm@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx/ 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
