Re: Our cumbersome mailing list workflow

[Michael Haggerty <mhagger@alum.mit.edu>]

On 11/27/2014 11:53 PM, Eric Wong wrote:
> Torsten Bögershausen <tboegi@web.de> wrote:
>> On 2014-11-25 01.28, Michael Haggerty wrote:
>>> [...]
>> In short:
>> We can ask every contributor, if the patch send to the mailing list
>> is available on a public Git-repo, and what the branch name is,
>> like _V2.. Does this makes sense ?
> 
> Not unreasonable.  I hope that won't give folks an excuse to refuse
> to mail patches, though.  Some folks read email offline and can't
> fetch repos until they're online again.

My ideal would be to invert the procedure. Let the patches in a public
Git repository somewhere be the primary artifact, and let the review
process be focused there. Let email be an alternative interface to the
central review site:

* Generate patch emails (similar to the current format) when pull
requests are submitted.

* Generate notification emails when people comment on the patches.

* Allow people to respond to the patch and notification emails via
email. The central review site should associate those comments with the
patches that they apply to, and present them along with other review
comments received via other interfaces.

>> I like Gerrit as well.
>> But it is less efficient to use, a WEB browser is slower (often), and
>> you need to use the mouse...
> 
> IMNSHO, development of non-graphical software should never depend on
> graphical software.  Also, I guess there is no way to comment on Gerrit
> via email (without registration/logins?).

The days of the vt52 are over. I'm an old neckbeard myself and have used
*real* vt52s. But these days even my *cellphone* is able to handle the
GitHub website [1]. Rejecting modern technology is not intrinsically
virtuous; it only makes sense if the old technology is really superior.
And it is not enough for it to be superior only for neckbeards; it
should be superior when averaged over all of the people whose
participation we would like to have in the Git project.

And by the way, there are text-only clients for interacting with GitHub [1].

> Lately, I've been trying to think of ways to make collaboration less
> centralized.  Moving to more centralized collaboration tools is a step
> back for decentralized VCS.

If an efficient decentralized collaboration system existed, then I'd
love to give it a chance. But as far as I know, the existing systems are
all embryonic.

Don't forget that even our current system is centralized to some extent.
There is a single mailing list through which all emails pass. There are
a few email archives that we de facto rely on (and it is a brittle
dependency--if Gmane were to disappear, we would have an awful lot of
broken URLs in our emails that would be impossible to fix).

It seems like a few desirable features are being talked about here, and
summarizing the discussion as "centralized" vs "decentralized" is too
simplistic. What is really important?

1. Convenient and efficient, including for newcomers
2. Usable while offline
3. Usable in pure-text mode
4. Decentralized

Something else?

In my opinion, a central system with good Git integration (helps with 1)
and both a straightforward web UI (also helps 1) and a good email
interface (which gives both 2 and 3) and the ability to export the
review history (which avoids lockin, the most important aspect of 4)
would be perfect. Is there such a thing?

Michael

[1] ...probably other websites too. I'm really not trying to flog GitHub
here; it's just the one I have the most experience with. In fact, I
kindof assume that the Git project would choose a service that is itself
based on open-source software.

-- 
Michael Haggerty
mhagger@alum.mit.edu