Most active commenters

    ←back to thread

    414 points st_goliath | 13 comments | | HN request time: 0.463s | source | bottom
    Show context
    Trasmatta ◴[] No.43971964[source]
    Only tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
    replies(3): >>43972038 #>>43972137 #>>43972641 #
    1. teddyh ◴[] No.43972038[source]
    Please, inform us of an alternative which is:

    • Non-proprietary

    • Federated

    • Archivable

    • Accessible

    • Not dependent on a specific company

    replies(3): >>43972053 #>>43972350 #>>43976439 #
    2. Trasmatta ◴[] No.43972053[source]
    I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.
    replies(1): >>43972176 #
    3. walterbell ◴[] No.43972176[source]
    Email is a root-of-trust for authentication in most non-email systems.
    4. zoobab ◴[] No.43972350[source]
    GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
    replies(5): >>43972460 #>>43972651 #>>43972708 #>>43972943 #>>43976965 #
    5. HappMacDonald ◴[] No.43972460[source]
    GIT is non-proprietary and decentralized so it keeps that promise.

    And having a built-in issue tracker

    1. isn't related to those properties, and

    2. isn't truly within the scope of a source code version control management solution.

    That's the domain of project management.

    6. somat ◴[] No.43972651[source]
    Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
    replies(2): >>43972824 #>>43974016 #
    7. delfinom ◴[] No.43972708[source]
    For large projects like the Linux kernel as an example out of many, I would assume the built-in issue tracker would end up 100x the size of the code base in storage space. lol
    8. badmintonbaseba ◴[] No.43972824{3}[source]
    Issues shouldn't really live in the same source tree, IMO. But AFAIK there are forges that keep the issues in the same repository, just not in the same tree of commits that the source tree has, git notes style.
    9. graemep ◴[] No.43972943[source]
    Fossil has one. If its something you want use Fossil - which I think is a great alternative for small teams, on the other hand, this is probably not something large teams (which are a high priority for git) want.
    10. rixed ◴[] No.43974016{3}[source]
    Any user without commit permission should be able to create tickets and comment on them.

    What's wrong with debbugs? :)

    11. Eduard ◴[] No.43976439[source]
    - horrible usability

    - can only participate in conversations via e-mails

    - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

    - NOT accessible, especially in the disabilities sense

    - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

    - no responsive design, tiny text and horizontal scrolling on mobile phone screens

    - sends you your password in cleartext via e-mail

    - actually complicated to unsubscribe from a list / manage your membership

    replies(1): >>43977888 #
    12. jbaber ◴[] No.43976965[source]
    If I ever get around to writing my git issue tracker, everything will be stored in a completely separate reponame-issues.git
    13. teddyh ◴[] No.43977888[source]
    > - horrible usability

    The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.

    > - can only participate in conversations via e-mails

    Um, yes, a mailing list uses e-mail. I don’t know what you expected.

    > - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox

    If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.

    Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.

    > - NOT accessible, especially in the disabilities sense

    Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.

    > - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability

    Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.

    > - no responsive design, tiny text and horizontal scrolling on mobile phone screens

    Again, a client issue. Get a better e-mail client.

    > - sends you your password in cleartext via e-mail

    Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.

    > - actually complicated to unsubscribe from a list / manage your membership

    Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.