12 ms·

Centralizing around proprietary software is not a good idea generally. Git is distributed, so when GitHub goes down, every developer has a backup of entire his

Centralizing around proprietary software is not a good idea generally. Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use "issues" feature for good. One way to avoid email without centralization is setting up Gerrit. That is how Ring [1] and LineageOS (former CyanogenMod) [2] manage their "pull requests". Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects, such as all suckless [3] projects and Linux itself. [1] https://gerrit-ring.savoirfairelinux.com/ https://gerrit-ring.savoirfairelinux.com/ [2] https://review.lineageos.org/ https://review.lineageos.org/ [3] http://suckless.org/ http://suckless.org/

fake-name 10y ago
Anything is better then e-mail based systems. The discoverability, browsability, and useability of something with actual markup and design is infinitely better then e-mail. I've tried several times to make submissions to several e-mail based projects, never with any success. At the same time, I've had zero issues contributing to a dozen or so github hosted projects. E-mail systems are a shitshow. First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!), send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc.... Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors. If there's a project where I want to make a few-line change or minor enhancement, and it's on github, I'll generally PR it back into the original. If it's somewhere else, or requires another account, there's no way I'm going to spend the effort. Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. They all operate on a per-message response-tree structure, so just reading the discussion is a huge pain in the ass. E-mail is basically dying among younger people, including the ones that code, and with good reason. For actual forum-type discussions, it's a completely shit solution.
- ycmbntrthrwaway 10y ago
  > First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. You can usually just send your patch to mailing list without joining at all and you will be replied off the list. > Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!) Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace. > Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.
  - mememachine 10y ago
    Why would anyone have to deal with diff files during regular usage?
    - username223 10y ago
      Let's say I found a bug in some software I use, and tweaked a few lines to fix it. Now what do I do? (1) Mail a diff to the author. (2) Get an account on some random website, "fork" the code, make the tweak again, and "submit a pull request." I'll choose (1) every time, and will probably just shrug and move on if I'm forced to do (2). I've made a few throwaway GitHub accounts when I cared enough, but I usually don't bother.
      - vopi181 10y ago
        I don't like the centralization around a proprietary software, but saying GitHub is a random site isn't fair. A lot of F/OSS people use it. Out of curiosity what happens when you want to submit say a picture to a repo?
        10y ago
Tharre 10y ago
If you're worried about losing issues, then just backup them using Github's API and some script[0]. [0] https://gist.github.com/Tharre/706b0d8c3567c1f5346a https://gist.github.com/Tharre/706b0d8c3567c1f5346a
mathgeek 10y ago
> Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. While I agree it's a good skill, this statement implies that anyone who doesn't use it it somehow arbitrarily "less important" than someone who does, when it comes to contributing to open source.
ajdlinux 10y ago
Everyone I know who has had to use Gerrit has absolutely, utterly despised it. Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days. The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives. But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments. I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development better?
- deleted 10y ago
  [deleted]
- rando832 10y ago
  I used gerrit and did not utterly despised it. Hi.
  - ajdlinux 10y ago
    Well I'm glad someone likes Gerrit. :D
  - mugsie 10y ago
    I have been using it for a few years, and I miss it when I am working on github projects :/
theamk 10y ago
> Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use "issues" feature for good. um, no? PEP-512 ( https://www.python.org/dev/peps/pep-0512/ https://www.python.org/dev/peps/pep-0512/ ) is pretty clear about it: "The code review history does not have the same implicit backup mechanism as the repository itself. That means a daily backup of code review history should be done so that it is not lost in case of any issues with GitHub."
cx1000 10y ago
I commented on this in another thread, but I'll repeat it here. The guy in charge of making the decision weighed the fact that it's closed source, and it still won. > But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform. In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py... My personal feeing on the matter is that proprietary software can harness a lot of talent and usually delivers a better end user experience. For example, the creator of Twitter Bootstrap works for github full time. How else will you get talented people thinking about how to make a product better all day?
forrestthewoods 10y ago
I agree relying on proprietary platforms which may shutdown is a good thing. I'd go so far as to say all platforms inevitably WILL shutdown. But GitHub issues can be exported pretty easily. Exported and saved in the distributed Git repository even. I think relying on a platform is perfectly fine if you have an exit strategy. I've moved my blog through multiple platforms. I even maintain the domain so old URLs continue to work. Will Medium shut down? Yes. And when it does I'll move my blog again. It won't be the first time and it won't be the last.
ghostly_s 10y ago
> Python does not use "issues" feature for good. Interesting, I didn't even know you could disable 'Issues' for a Github repo. Why do I come across so many projects where the dev lets random issues pile up which they clearly have no intention of responding to, then?
komali2 10y ago
I mean, I want to consider myself a hacker, but I have no interest in OS programming, and everything I am interested in is on Github.
mayneack 10y ago
If you subscribe to a github repo you get issue emails by default. So issues could still be "backed up" by email on github.
manigandham 10y ago
> Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects What? That sounds like a problem with the projects, not the people. Why make it so much harder to get contributions?

fake-name 10y ago

Anything is better then e-mail based systems. The discoverability, browsability, and useability of something with actual markup and design is infinitely better then e-mail. I've tried several times to make submissions to several e-mail based projects, never with any success. At the same time, I've had zero issues contributing to a dozen or so github hosted projects. E-mail systems are a shitshow. First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!), send an e-mail, find the mailing list shat itself and troubleshoot, try again, etc.... Basically, e-mail is the death of any sort of low-effort contribution. If you're starting a new project, and chose a mailing list, you're probably excluding a huge quantity of potential contributors. If there's a project where I want to make a few-line change or minor enhancement, and it's on github, I'll generally PR it back into the original. If it's somewhere else, or requires another account, there's no way I'm going to spend the effort. Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. They all operate on a per-message response-tree structure, so just reading the discussion is a huge pain in the ass. E-mail is basically dying among younger people, including the ones that code, and with good reason. For actual forum-type discussions, it's a completely shit solution.

ycmbntrthrwaway 10y ago
> First, you generally have to join a mailing list, which is regularly broken, or requires someone somewhere to manually acknowledge your membership. You can usually just send your patch to mailing list without joining at all and you will be replied off the list. > Then, you have to figure out how they want shit formatted, figure out how to generate a diff (I've been using SVN for 8+ years, git for ~3 years, and have never had to deal with diff files!) Unbelievable. The only explanation I can find is that you avoided dealing with diffs and used SVN only on your workplace. > Plus, just reading mailing lists is a fucking disaster. Literally no mailing list host I know of lets you just view a complete topic thread in simple chronological order on ONE PAGE. Mailing lists are supposed to be read in your email client. If you want an archive, use NNTP archive like gmane.
- mememachine 10y ago
  Why would anyone have to deal with diff files during regular usage?
  - username223 10y ago
    Let's say I found a bug in some software I use, and tweaked a few lines to fix it. Now what do I do? (1) Mail a diff to the author. (2) Get an account on some random website, "fork" the code, make the tweak again, and "submit a pull request." I'll choose (1) every time, and will probably just shrug and move on if I'm forced to do (2). I've made a few throwaway GitHub accounts when I cared enough, but I usually don't bother.
    - vopi181 10y ago
      I don't like the centralization around a proprietary software, but saying GitHub is a random site isn't fair. A lot of F/OSS people use it. Out of curiosity what happens when you want to submit say a picture to a repo?
      - 10y ago

Tharre 10y ago

If you're worried about losing issues, then just backup them using Github's API and some script[0]. [0] https://gist.github.com/Tharre/706b0d8c3567c1f5346a https://gist.github.com/Tharre/706b0d8c3567c1f5346a

mathgeek 10y ago

> Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. While I agree it's a good skill, this statement implies that anyone who doesn't use it it somehow arbitrarily "less important" than someone who does, when it comes to contributing to open source.

ajdlinux 10y ago

Everyone I know who has had to use Gerrit has absolutely, utterly despised it. Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days. The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives. But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments. I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development better?

deleted 10y ago
[deleted]
rando832 10y ago
I used gerrit and did not utterly despised it. Hi.
- ajdlinux 10y ago
  Well I'm glad someone likes Gerrit. :D
- mugsie 10y ago
  I have been using it for a few years, and I miss it when I am working on github projects :/

theamk 10y ago

> Git is distributed, so when GitHub goes down, every developer has a backup of entire history. However, issues are lost forever. Python does not use "issues" feature for good. um, no? PEP-512 ( https://www.python.org/dev/peps/pep-0512/ https://www.python.org/dev/peps/pep-0512/ ) is pretty clear about it: "The code review history does not have the same implicit backup mechanism as the repository itself. That means a daily backup of code review history should be done so that it is not lost in case of any issues with GitHub."

cx1000 10y ago

I commented on this in another thread, but I'll repeat it here. The guy in charge of making the decision weighed the fact that it's closed source, and it still won. > But to me, the development process is more important than worrying whether a cloud-based service publishes its source code... This is especially not a worry as GitHub is not a walled garden; its extensive SDK allows for downloading any and all data that goes into the platform. In summary, his reasons were: github has become a social network of open source devs; gitlab has no killer features github doesn't; and Guido prefers github https://snarky.ca/the-history-behind-the-decision-to-move-python-to-github/ https://snarky.ca/the-history-behind-the-decision-to-move-py... My personal feeing on the matter is that proprietary software can harness a lot of talent and usually delivers a better end user experience. For example, the creator of Twitter Bootstrap works for github full time. How else will you get talented people thinking about how to make a product better all day?

forrestthewoods 10y ago

I agree relying on proprietary platforms which may shutdown is a good thing. I'd go so far as to say all platforms inevitably WILL shutdown. But GitHub issues can be exported pretty easily. Exported and saved in the distributed Git repository even. I think relying on a platform is perfectly fine if you have an exit strategy. I've moved my blog through multiple platforms. I even maintain the domain so old URLs continue to work. Will Medium shut down? Yes. And when it does I'll move my blog again. It won't be the first time and it won't be the last.

ghostly_s 10y ago

> Python does not use "issues" feature for good. Interesting, I didn't even know you could disable 'Issues' for a Github repo. Why do I come across so many projects where the dev lets random issues pile up which they clearly have no intention of responding to, then?

komali2 10y ago

I mean, I want to consider myself a hacker, but I have no interest in OS programming, and everything I am interested in is on Github.

mayneack 10y ago

If you subscribe to a github repo you get issue emails by default. So issues could still be "backed up" by email on github.

manigandham 10y ago

> Still, being able to submit patches via email is an absolutely necessary skill for everyone who considers himself a hacker. Lack of it makes you unable to contribute to many great projects What? That sounds like a problem with the projects, not the people. Why make it so much harder to get contributions?