1. 61
  1.  

  2. 24

    I was thinking of writing this blog post too. Maybe I still will, because I want to emphasise something different about this topic.

    Mailing list workflows also make people write a different sort of commit, where the diffs are short and readable and the commit messages are persuasive as to why the diff should be accepted. That’s because these diffs and commit messages are going to be much more prominent in people’s mailboxes, so both should be as readable as possible. Extraneous things such as style fixes or whitespace changes within the same diff are frowned upon because they bring clutter and hinder readability (it’s okay to throw those into a separate commit and thus a separate email, though).

    I find this style of commits immensely useful when reading the project’s history, but their value is hard to convey to someone raised on Github, which strongly discourages this style of commits. Most Github users I’ve seen never read the project’s history, because they value neither writing nor reading it.

    1. 9

      Most Github users I’ve seen never read the project’s history, because they value neither writing nor reading it.

      My impression as to why that is that because navigating the history of a particular code segment in GitHub is hard to do, people do it less often. Because they seldom read the history, they don’t value writing it (why waste effort in something that no-one will read?), instead they worry about the pull request message, which is out of band information for the VCS.

      Because commits are easy to navigate using Emacs’ vc-annotate mode, I’ve found valuable information written down 7+ years when working in FLOSS projects where the original author was long gone. And since then I tend to value well written commit messages.

      1. 10

        As I was saying in HN, I think Github did to commits and commit messages what Gmail did to email and top-posting: hide most of it so that nobody has to bother with writing it properly and thus doesn’t have to read it either.

      2. 8

        I’m 100% with you on this. I think this is a consequence of GitHub’s “code first” attitude; the UI presents code front and center, so that’s what people come to care about. Commit messages and project history are second class citizens on GitHub, which saddens me - there’s a lot of useful information locked away in there! If you get around to writing that post, I would very much like to read it!

      3. 11

        I feel like we’re missing a central piece of the discussion here–the creation of, and maintenance of mailing lists. The post touches on it, but it’s a hassle to host your own email. The community, as a whole, would benefit from some innovation in mailing list hosting and interactions. I’ve not seen anyone even enter this space since Librelist… close to 10 years ago at this point. And, Librelist seems to be rotting…

        1. 1

          Man, I don’t think I’ve setup a Mailman instance for a project since like 2012.

        2. 7

          Do not top-post.

          Keep quoted text small and relevant

          Sadly, this advice is just not followed most of the time on the mailing lists I follow. As much as top-posting bothers me, I have to resign myself to the fact that demanding it is basically me becoming the old man who yells at clouds. All attempts to stop it by others have not worked. I don’t think it’s going away.

          1. 1

            List managers could stop it by bouncing top-posts.

            1. 1

              I still reply to e-mails with top posts (although I’m on very few mailing lists these days and contribute to nearly zero).

              At least with personal e-mails, it makes more sense for your reply to be at the top and not have to scroll all the way to the bottom.

              But whatevs. It’s tabs vs spaces at this point.

              1. 3

                You shouldn’t have to scroll far - you only quote enough to make it clear what you are talking about, then you talk about it. If you want to see the whole message, you can just go back to the other email.

                1. 2

                  An apt comparison, just like so-called “tabs-vs-spaces” the claim that there are two equivalent options misses the point entirely.

                  The point is not to uselessly quote everything and put your post at the bottom instead of uselessly quoting everything and putting your post at the top. The point is to stop uselessly quoting everything.

                2. 1

                  This particular battle is lost. I doubt there is any mail client with more than 3% marketshare that does not use top-posting as standard.

                  In the business world, where clients like Outlook hold sway, someone who doesn’t top post and doesn’t drag along the entire previous conversation (including disclaimer signatures, cutesy “consider the environment before printing this email” PNGs, and potentially embarrassing discussions of someone who was just added as a CC by a 3rd party) is seen as a weirdo.

                3. 11

                  To me, a mailing list-oriented project has a major disadvantage: the lack of a simple, quick and reliable way to judge it.

                  GitHub offers a more-or-less standardized interface. When I look at a repo, I can get a feeling for it’s size, maturity, relibility, etc. (And of course this can be faked and I can be manipulated, but that’s a different issue). If some project has 20 starts and an alternative has 800, I would invest time into the latter before I compare it to the first. The ammount of issues and pull-requests offer a good heuristic when it comes to how active a project is. And so on.

                  But when such a repo is lacking, or even when it’s hosted on some other platform/with a different tool (GitLab, Gogs, CGit, stagit, …) all of this meta-information disappears. Open-source names tend to be quite meaningless, project descriptions too concise: comparing, choosing and discovering tools becomes far more tiresome – hence I argue that if a strong alternative to GitHub is to appear, it doesn’t even have to replicate every technical feature, but be capable of reflecting quality, effort, maturity, etc.

                  I have therefore been arguing for a while to create a unifiying interface based on maling lists, GPG, Git, etc. that woudln’t rely on one platform or backend (ultimatly even using GitHub!), “gluing” these together to fulful the “social” aspect of “social coding”. After all, it should be obvious to anyone that unless one tries to replicate GitHub size-wise, the technical side isn’t really the thing that is keeping the site alive.

                  1. 4

                    Ultimately the control and customizability enjoyed by the mailing list style of development comes from diverse tools built for open standards. […] SMTP has an RFC.

                    SMTP has an RFC, but sadly it’s not particularly relevant. We live in a world where Google and a handful of other companies have a near-monopoly on the protocol, and if you want to run a server that can actually send mail to the people who use Google, you have to play by their ever-shifting rules. If they decide to blacklist you, there’s no accountability or appeals process to get your server functional again.

                    As much as I want this to happen (because being able to choose your own client is really wonderful), the lack of a realistic ability to choose your server kills it for me.

                    1. 4

                      One of the downsides of mailing lists: git send-email is scary. Using it for the first time fills you with dread. You worry about sending everything right.

                      Then possibly there’s a moderation delay (e.g. on freedesktop lists).

                      Then the project owners don’t see your mail for a long time because they use goddamn Gmail, which in its infinite wisdom counts you as a spammer if your domain has strict SPF policies and you send mail to mailing lists, which mail others on your behalf from a server you didn’t approve…

                      1. 2

                        Some good, comprehensive information there. My own projects are too small to need mailing lists, although I did once receive a patch via email :)

                        A couple of points about the content:

                        • The article recommends using git’s --mirror option but I seem to recall some bad experience trying that in the past, so I always use --bare instead.
                        • The article also mentions BugsEverywhere, which I tried to use some years ago but it seemed to be dead (submodules weren’t resolving, etc.). I considered forking, but it seemed dauntingly overengineered for what I needed. Instead I use artemis which is very simple.

                        My own setup has been evolving over the years, but it would be nice to have a command to make a “skeleton” project, with a mailing list, repo URL, CI setup, etc. There’s probably too much variation among those things for people to agree; so far I use a script which can take a local git repo and set up a bare clone on my Web server, set up some hooks for rendering static pages, etc.

                        1. 2

                          I really like this post. I think it’s very fair to the complaints that people have about email-based contribution flows.

                          Some helpful things to add to this article:

                          • Mentioning git am, git format-patch, git request-pull and git send-email

                          This seems targeted at the got crowd, and git has a bunch of wrappers to make this flow easier. It seems worth mentioning.

                          • Hosted mailing list options

                          Setting up a mail server right can be difficult, especially if systems administration isn’t your wheelhouse. Like literally any service, it requires a non-zero amount of maintenance and monitoring. It might be worth bringing up options like Google groups, freelists (I’ve contributed to a project using freelists oddly enough) or any others.

                          1. 2

                            If we’re going to do mailing lists then we really need to improve the user experience for people who are not on linux and are not familiar with the terminal. Not every contributor is technically savvy, often they are making changes to the verbiage or the visuals and they are using a graphical interface for git. The success of github is a stark example of how much this is needed. When you work on improving the user experience of mailing lists make sure to include someone who has pretty low technical experience. Make sure to create graphical interface options.

                            1. 2

                              Interestingly, the original GH workflow was not that different from mailing lists. It had the Fork Queue: https://blog.github.com/2008-12-16-the-fork-queue/

                              It would be a list of all patches on all forks which you could pick. You would inform the maintainer that you have a patch ready and where it was.

                              What I find amazing is that none of the competing products to GH came up with a different workflow then GH style PRs. It’s definitely one of their most opinionated pieces and I see a lot of room there (even for lightweight workflows!).

                              1. 2

                                Once you subscribe to a mailing list, new messages flow into your client and are available for searching. Hooray! But what about messages sent before you joined the list? Furthermore, how do you “link” to old messages from newer ones?

                                This is the same problem that killed xmpp, irc and other older instant messengers, when newer messengers appeared (whatsapp, slack, etc). Older messengers were just forwarding messages, newer treat chat more like document edited by multiple users. Mailing list archives are afterthought, just like xep-0313. NNTP, mentioned in article, has this feature, but has lots of other problems.

                                1. 1

                                  The vcs tag doesn’t really apply here, I would say.

                                  1. 16

                                    I disagree. Both git and Mercurial were built with a mailing list workflow in mind. This is why git has the commands git am, git format-patch and git request-pull and Mercurial has hg export and hg import as well as hg email.

                                    Also, mailing lists were the original distributed VCS. The versions are all there, in everyone’s mailboxes. There’s a lot of mailing list heritage in the functionality of our current VCSes.

                                  2. 1

                                    Got a colleague that emails his versions to himself.. Always thought he was crazy but perhaps I should think again.

                                    1. 1

                                      Interacting with project mailing lists makes me wish they were really newsgroups. Having two disjoint interfaces for the archive and updates is frustrating.