On 11/27/2014 11:53 PM, Eric Wong wrote: > Torsten Bögershausen <tbo...@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 mhag...@alum.mit.edu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
