Hacker News Reader

Comment by fake-name | Hacker News Reader

Downside: Holy shit fuck mailing lists. They're terrible.

Major downside: You miss a huge percentage of possible contributors.

This is fairly sad, because a lot of software is still maintained using mailing lists. Often not because it's the best solution, but because it's the least bad (for some). Also, if one wants to ensure that the whole lineage will be with us 20 years from now, a mailing list is a better bet than all the Gerrits and Githubs of the world.

I remember I wanted to check out what was happening in Postgres, since it's my favourite database. But the sheer complexity of getting to the code diffs and comments and all that... I quickly gave up, because the environment was rather unfriendly to newcomers (actually, I didn't completely give up, I just browsed the Github mirror, which was the only usable part of their version control).

And I'm not blaming them, it works well for the core devs, but they can't expect many new contributors (and contributions are even things like documentation, tests etc.!). Which is a pity.

I'd argue that if one wants to ensure that the whole lineage will be with us 20 years from now, the first step is to make sure that the software is still alive 20 years from now. And using a mailing list is a good way of starving your project to death, if you're not Git or Linux or Postgres.

And I'm even worried about those... what will happen in a few years/decades from now, when the generation of devs that are using mailing lists is not active anymore?

> Also, if one wants to ensure that the whole lineage will be with us 20 years from now, a mailing list is a better bet than all the Gerrits and Githubs of the world.

Unfortunately, email lists are not easy to browse if you're not subscribed and browsing past messages from before you described isn't that easy. The easiest way I've found around that problem is to use an email to NNTP gateway like gmane. Though that makes me wonder why project discussion isn't managed via a newsgroup as opposed to an email list.

Postgres' archives aren't that bad. You can find things via $search_engine, view by time, thread view crosses months etc: https://www.postgresql.org/list/pgsql-hackers/

It apparently doesn't present a threaded view like a mail/news client would and downloading the mbox file requires one to authenticate with the server.

> It apparently doesn't present a threaded view like a mail/news client would

Not the same as a mail client, but once you opened an individual email there's threaded structure.

> and downloading the mbox file requires one to authenticate with the server.

It does, but also says “Please authenticate with user archives and password antispam” - it's just to make automated extraction of email addresses a bit more work.

> Not the same as a mail client, but once you opened an individual email there's threaded structure.

Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

Though I wish that having a NNTP gateway (or using NNTP as a primary method of communication for a project) was the standard as opposed to using a mailing list since it would make viewing past messages before subscribing to a newsgroup trivial.

> Yes, but it's much more cumbersome to navigate the thread compared to using an actual mail client. If web pages of mail archives could present an overview pane for navigating messages, it would go a long way to making them usable in a browser as opposed to just posting links to the immediate parent and the set of children for a given message.

It does, although discovery of the feature as well as the feature itself could use some improvement. In the header there's "Thread:" and the associated button displays the structure. You can also open a whole thread, but I don't find that particularly useful. The download mbox link inside a message will give you the whole thread as well.

Not all mailing list archivers are created equal.

For my own site, I rejected the awful Pipermail (default archiver with GNU Mailman) with its brutally ugly presentation format and text-only.

I found an alternative called Lurker, with a better web interface and some of the features you're mentioning, like threading.

I further customized Lurker. I gave it a button bar with custom icons, and hacked it to support in-line HTML (when people post HTML to the mailing list, it is integrated into the archive as HTML). Because that is dangerous, of course, I wrote a comprehensive HTML cleaner for that.

I welcome HTML in my mailing lists; it's time for mailing lists to retire "text only" rules. It improves the formatting of text, letting you use typewriter fonts, italics and bold appropriately, and real bullets.

Here is an archive message with in-line images, another benefit:

http://www.kylheku.com/lurker/message/20131110.004036.5ed128...

Here is discussion where you can see a branched tree view:

http://www.kylheku.com/lurker/message/20121127.210005.0ca78d...

Lurker mods: http://www.kylheku.com/cgit/lurker/

HTML cleaner: http://www.kylheku.com/cgit/hc/tree/

This lexically analyzes the HTML and filters out all unwanted tags, or unwanted attributes of otherwise wanted tags.

mbox archives reveal people's e-mails; you have to control access to those.

By the way, here is the Lurker author's response to my changes:

https://sourceforge.net/p/lurker/mailman/message/31487163/

TL; DR: Irrationally against all HTML in mail archives, even if properly cleaned. Thanks for Lurker, though!

> http://www.kylheku.com/lurker/message/20121127.210005.0ca78d....

That does look better compared to other web interfaces I've seen in the past (though you still have to hover over the icon to view details of a message like the author and subject).

One decent interface I've seen is public-inbox (https://public-inbox.org/git/). It presents an overview with the subjects and threading and allows for downloading mbox files or using an atom feed link.

The nice thing is that these can be used in parallel. Using Lurker doesn't preclude me from also setting up public-inbox as an alternative presentation of the same archives.

> (actually, I didn't completely give up, I just browsed the Github mirror, which was the only usable part of their version control).

What makes our git own git repo unusable?

https://git.postgresql.org/gitweb/?p=postgresql.git;

I personally find that quicker to get around in than github.

Man, why doesn't gitweb serve up the clone links as links that you can right click and copy?

You have to swipe the cursor over "https://git.postgresql.org/git/postgresql.git" and copy; how lame.

CGIT is so much nicer. It also serves up tarballs out of tags. If you do a "git tag foo-123" and push it out, then on your CGIT interface, there will be a foo-123.tar.gz URL for download (as well as .bz2 and .zip), pulled right out of the repo.

Still, either is light years ahead of github's presentation of repos.

> What makes our git own git repo unusable?

I know; WTF? From grandparent's comment I got the impression that Postgresql must be using CVS, or just tarballs in a FTP directory or something (and that someone kindly made a git repo and put it into GH).

> Holy shit fuck mailing lists. They're terrible.

What do you find terrible about them? When browsing email lists like the one used for developing git itself, I find it very easy to go through various patch sets and follow the discussion they have on each commit. My client makes it easy to search for subjects, expand or collapse threads, search for authors, etc.

The emails themselves are easy to read and don't require an excessive amount of scrolling to go through even if the patch set has multiple commits. It's quite easy to see comments on a patch set inline with the patch itself.

I love mailing lists. They're a natural filter and get rid of a lot of the demographic you don't want in the first place.

Solution: gitlab, gitea and gogs exist.

Same advantages of self hosting, simple UI for inexperienced users, all the ability to control your own stuff.

I don't want to deal with people who think e-mail is terrible, or contributors who can't copy a URL from a page served up CGIT, do a "git clone" on it, and then mail off the results of "git format-patch" when they are done. This stuff is incredibly easy.

It's not about email being easy. It's that I don't want my email getting out (spam and all that - you send one email to a bad behaving mailing list, and your email is all over the internet forever for spambots to harvest.)

Realistically if you've got commits in a public git repo, your email address is public no matter how they got there.

Realistically, people concerned about that (or just being lazy) don't put real e-mail addresses in there.

You can post using a fake or cloaked From: address to my mailing lists. I don't require a subscription for posting. You can always check the mail archive for replies to your post, if you care. I don't allow mail archives to be downloaded in the raw format. I added extra patches to the archiving software to conceal addresses better.

Mailman just replaces @ with "at" which spam harvesters could easily reverse; I made it better for my users; see below.

Kazinator's got your back!

  0:webserver:/var/lib/mailman# quilt applied
  privacy
  pipermail-to-lurker

  0:webserver:/var/lib/mailman# cat patches/privacy
  Index: mailman/Mailman/Archiver/HyperArch.py
  ===================================================================
  --- mailman.orig/Mailman/Archiver/HyperArch.py        2012-11-29 21:26:57.000000000 -0800
  +++ mailman/Mailman/Archiver/HyperArch.py     2012-11-29 22:27:51.000000000 -0800
  @@ -93,6 +93,8 @@
       True = 1
       False = 0

  +def hide_domain(s):
  +    return re.sub(r'([\w])([-+,.\w]+)([\w])@([\w])([-+.\w]+)([\w])[.]([\w]+)', '\g<1>...\g<3>@\g<4>...\g<6>.\g<7>', s)

   def html_quote(s, lang=None):
  @@ -281,10 +283,9 @@
               try:
                   i18n.set_language(lang)
                   if self.author == self.email:
  -                    self.author = self.email = re.sub('@', _(' at '),
  -                                                      self.email)
  +                    self.author = self.email = hide_domain(self.email)
                   else:
  -                    self.email = re.sub('@', _(' at '), self.email)
  +                    self.email = hide_domain(self.email)
               finally:
                   i18n.set_translation(otrans)

  @@ -412,9 +413,7 @@
                   otrans = i18n.get_translation()
                   try:
                       i18n.set_language(self._lang)
  -                    atmark = unicode(_(' at '), Utils.GetCharSet(self._lang))
  -                    subject = re.sub(r'([-+,.\w]+)@([-+.\w]+)',
  -                              '\g<1>' + atmark + '\g<2>', subject)
  +                    subject = hide_domain(subject)
                   finally:
                       i18n.set_translation(otrans)
               self.decoded['subject'] = subject
  @@ -466,7 +465,7 @@
               d["in_reply_to_url"] = url_quote(self._message_id)
               if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
                   # Point the mailto url back to the list
  -                author = re.sub('@', _(' at '), self.author)
  +                author = hide_domain(self.author)
                   emailurl = self._mlist.GetListEmail()
               else:
                   author = self.author
  @@ -574,10 +573,8 @@
           if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
               otrans = i18n.get_translation()
               try:
  -                atmark = unicode(_(' at '), cset)
                   i18n.set_language(self._lang)
  -                body = re.sub(r'([-+,.\w]+)@([-+.\w]+)',
  -                              '\g<1>' + atmark + '\g<2>', body)
  +                body = hide_domain(body)
               finally:
                   i18n.set_translation(otrans)
           # Return body to character set of article.
  @@ -1049,7 +1046,7 @@
           author = self.get_header("author", article)
           if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
               try:
  -                author = re.sub('@', _(' at '), author)
  +                author = hide_domain(author)
               except UnicodeError:
                   # Non-ASCII author contains '@' ... no valid email anyway
                   pass
  @@ -1221,7 +1218,7 @@
                       text = jr.group(1)
                       length = len(text)
                       if mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS:
  -                        text = re.sub('@', atmark, text)
  +                        text = hide_domain(text)
                           URL = self.maillist.GetScriptURL(
                               'listinfo', absolute=1)
                       else:
  Index: mailman/Mailman/Utils.py
  ===================================================================
  --- mailman.orig/Mailman/Utils.py     2012-11-29 21:26:57.000000000 -0800
  +++ mailman/Mailman/Utils.py  2012-11-29 21:26:58.000000000 -0800
  @@ -438,9 +438,9 @@
       When for_text option is set (not default), make a sentence fragment
       instead of a token."""
       if for_text:
  -        return addr.replace('@', ' at ')
  +        return 'address-hidden'
       else:
  -        return addr.replace('@', '--at--')
  +        return 'address-hidden'

   def UnobscureEmail(addr):
       """Invert ObscureEmail() conversion."""

Personally, I just feel more socially intimidated when sending email than opening a GitHub pull request. In an email I feel like there's more of an expectation of at least basic pleasantries, whereas on GitHub I feel like I can get away with writing a good, matter-of-fact commit message and just leaving that as the PR message. Of course, most people are not as inhibited as I am…

Would it help if there is a dedicated mail alias for patches? As in <project-patches@example.com>.

Niceties are off-topic there by definition so you don't have to worry.

Git writes e-mails out of commits: see the "git format-patch" command. You can practically send that straight to the mail command.

Reply on news.ycombinator.com