mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: ALBERTIN TIMOTHEE p1514771 <>
To: Junio C Hamano <>
Cc: "" <>,
	"" <>,
	"PAYRE NATHAN p1508475" <>,
Subject: RE: [PATCH 1/2] Documentation about triangular workflow
Date: Wed, 22 Nov 2017 15:55:46 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Daniel Bensoussan <> writes:

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

>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

      reply	other threads:[~2017-11-22 15:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 16:07 [PATCH 1/2] Documentation about triangular workflow Daniel Bensoussan
2017-11-17 16:07 ` [PATCH 2/2] Triangular workflow Daniel Bensoussan
2017-11-17 21:15   ` Martin Ågren
2017-11-17 20:01 ` [PATCH 1/2] Documentation about triangular workflow Stefan Beller
2017-11-17 21:11 ` Martin Ågren
2017-11-22 15:13   ` ALBERTIN TIMOTHEE p1514771
2017-11-18  1:33 ` Junio C Hamano
2017-11-22 15:55   ` ALBERTIN TIMOTHEE p1514771 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).