3 ms·

But you can still do distributed repos with github... nothing it preventing you from changing your remote origin...

nikivi 6y ago
Only issue is if you decide to use GitHub features like issues/prs or comments on code, those won't be transferrable I think. At least easily.
- Pfhreak 6y ago
  Is it really though? The tools might be proprietary, but the workflow should be easy to move. E.g. You need to have a code review before a commit is merged. It happens that Github has a good set of tools for this, but if you decided that on date X you wanted to move away I don't think it would be that hard to shift away. You'd have the same mandate about code review, you just point people at a different tool set to do it.
- kanox 6y ago
  Email archives are even harder to transfer, and to make sense of in general. For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
  - angio 6y ago
    > Email archives are even harder to transfer, and to make sense of in general. Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0]. > For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title. In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit. [0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archive%20into%20a%20new%20mailing%20list%3F https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...
  - Seirdy 6y ago
    > Email archives are even harder to transfer Mailing lists are trivial to distribute. Thanks to maildir and mbox, everybody has a full copy of the mailing list just as they have a full copy of the repository.
    - kanox 6y ago
      > Thanks to maildir and mbox, everybody has a full copy of the mailing list. No, that only covers emails that you personally received. You need another mechanism for older emails.
      - ddevault 6y ago
        A mechanism which is provided by mailing list archives in the form of mbox downloads. If you question the reliability of this (but apparently not the proven unreliability of GitHub), as a fallback you can just ask an older subscriber to give you their mbox.
deleted 6y ago
[deleted]
Seirdy 6y ago
If GitHub goes down, you can still use a different remote; however, you lose issues, PRs, and code review. If your remote goes down but you have an email based workflow, you can continue as if nothing happened. One could argue that your mail server might go down, but it’s better than having your centralized GitHub-like forge go down for two reasons: 1. If not all contributors use the same mail server, it’s much less of an issue since not everyone goes offline at the same time. Additionally, your maildir doesn’t care whether or not you’re online; both the git repo and all mailing lists have offline copies distributed to all collaborators out-of-the-box by default. 2. GitHub’s reliability is significantly poorer than the vast majority of email providers. The great thing about decentralization is that getting good uptime on a small mail server for under 1000 users is much easier than getting good uptime on a centralized forge re-implementing email’s features for millions of users.
- gregmac 6y ago
  You still have a single, centralized mailing list server. That's what you should be comparing to GitHub -- not the individual mail servers for each user. If your mailing list server goes down, no one can use the mailing list. Taking it a step further, if its data is lost, everyone has to re-subscribe. On top of that, you have a mailing list archive. If that's down, or not operating, you've made thing even less open, because now any non-subscribers can't even read what's going on, and if they do subscribe, they only get to see new messages. Existing long-time subscribers have an archive, sure, but it's very possible no one user has a complete archive, and it's a certainty that most users don't. Someone can run a redundant mailing list archive server, but then someone can also mirror the GitHub repository, PRs and issues. --- That said, the mailing list server and archive are likely simpler to run, less likely to go down, and easier to move somewhere else. Transferring from github.com to something else is going to be painful, and I suspect most FOSS authors simply don't think about it or see the ease and benefits of using it as outweighing the risk. Companies should look at that risk much more closely, but ultimately it's the same situation as if they decide not to have fire insurance: if their building burns down, they're SOL, but that was the decision they made.
  - 6y ago

Only issue is if you decide to use GitHub features like issues/prs or comments on code, those won't be transferrable I think. At least easily.

Pfhreak 6y ago
Is it really though? The tools might be proprietary, but the workflow should be easy to move. E.g. You need to have a code review before a commit is merged. It happens that Github has a good set of tools for this, but if you decided that on date X you wanted to move away I don't think it would be that hard to shift away. You'd have the same mandate about code review, you just point people at a different tool set to do it.
kanox 6y ago
Email archives are even harder to transfer, and to make sense of in general. For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title.
- angio 6y ago
  > Email archives are even harder to transfer, and to make sense of in general. Email archives are very easy to transfer, you simply download the mbox file from the old system and import them to the new one [0]. > For example if you want to find the review comment thread for linux commits there is no reliable way to do it, your best bet is to google the title. In my experience, projects that use a ml-based workflow have higher standards for commit messages and so the information about a commit is usually in the commit. [0] https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archive%20into%20a%20new%20mailing%20list%3F https://wiki.list.org/DOC/How%20do%20I%20import%20an%20archi...
- Seirdy 6y ago
  > Email archives are even harder to transfer Mailing lists are trivial to distribute. Thanks to maildir and mbox, everybody has a full copy of the mailing list just as they have a full copy of the repository.
  - kanox 6y ago
    > Thanks to maildir and mbox, everybody has a full copy of the mailing list. No, that only covers emails that you personally received. You need another mechanism for older emails.
    - ddevault 6y ago
      A mechanism which is provided by mailing list archives in the form of mbox downloads. If you question the reliability of this (but apparently not the proven unreliability of GitHub), as a fallback you can just ask an older subscriber to give you their mbox.

deleted 6y ago

[deleted]

Seirdy 6y ago

If GitHub goes down, you can still use a different remote; however, you lose issues, PRs, and code review. If your remote goes down but you have an email based workflow, you can continue as if nothing happened. One could argue that your mail server might go down, but it’s better than having your centralized GitHub-like forge go down for two reasons: 1. If not all contributors use the same mail server, it’s much less of an issue since not everyone goes offline at the same time. Additionally, your maildir doesn’t care whether or not you’re online; both the git repo and all mailing lists have offline copies distributed to all collaborators out-of-the-box by default. 2. GitHub’s reliability is significantly poorer than the vast majority of email providers. The great thing about decentralization is that getting good uptime on a small mail server for under 1000 users is much easier than getting good uptime on a centralized forge re-implementing email’s features for millions of users.

gregmac 6y ago
You still have a single, centralized mailing list server. That's what you should be comparing to GitHub -- not the individual mail servers for each user. If your mailing list server goes down, no one can use the mailing list. Taking it a step further, if its data is lost, everyone has to re-subscribe. On top of that, you have a mailing list archive. If that's down, or not operating, you've made thing even less open, because now any non-subscribers can't even read what's going on, and if they do subscribe, they only get to see new messages. Existing long-time subscribers have an archive, sure, but it's very possible no one user has a complete archive, and it's a certainty that most users don't. Someone can run a redundant mailing list archive server, but then someone can also mirror the GitHub repository, PRs and issues. --- That said, the mailing list server and archive are likely simpler to run, less likely to go down, and easier to move somewhere else. Transferring from github.com to something else is going to be painful, and I suspect most FOSS authors simply don't think about it or see the ease and benefits of using it as outweighing the risk. Companies should look at that risk much more closely, but ultimately it's the same situation as if they decide not to have fire insurance: if their building burns down, they're SOL, but that was the decision they made.
- 6y ago