3 ms·

Mailing lists. Many providers, easy setup. Pull requests are an artificial addition to git workflow, it was designed with email patches as the main way to send

Mailing lists. Many providers, easy setup. Pull requests are an artificial addition to git workflow, it was designed with email patches as the main way to send contributions. Bug tracking is fine with mailing lists too.

Avamander 7y ago
Mailings lists (and e-mail as such) are seriously cumbersome to use as a way to send contributions and even more so when you want to track bugs. Every email archive software also looks like it was made in the 80s and is disgusting, slow and unreasonably difficult to use and also lacks any kind of organizational features that issue trackers have. It is absolutely not "fine", it's borderline tolerable at best.
- ignaloidas 7y ago
  So you are saying that sending an e-mail is seriously cumbersome? Excuse me, but for me it is a lot more steps from local edit to a contribution using Github. For Github I (1) have to create a fork (2) set it as a remote in my local copy, or if I forgot how to do it, (2.1) pull another one and copy my changes to it, (3) push my changes to my fork, (4) open a pull request in Github, which takes 3 context switches. Meanwhile for email I (1) look at README to find the email of development mailing list, (2) set it up for git send-email(https://git-send-email.io/ https://git-send-email.io/) and (3) send my patches upstream, all with me staying withing my editor with an integrated terminal. No need to open up gmail or thunderbird, or even mutt or aerc. Contribution workflow is a lot more streamlined. If you don't like mailing lists for issue tracking, there is git-bug or plethora of different bugtracking software for you.
  - Avamander 7y ago
    Now you described only sending one patch. How do you deal with continuous integrations and making sure things like CLAs are signed? How does issue tracking integrate there? Answer: it doesn't, it's all a major PITA to arrange. > For Github I (1) have to create a fork (2) set it as a remote in my local copy, or if I forgot how to do it, (2.1) pull another one and copy my changes to it, (3) push my changes to my fork, (4) open a pull request in Github, which takes 3 context switches. You mean you don't create a fork by cloning the repository onto your PC when using e-mail? Or that somehow `git send-email` is harder than `git push`? I disagree having done both. I'd gladly remove `send-email` from git for it's negative effects on FOSS, it's clearly making people think it's somehow nice to use or start using. > there is git-bug or plethora of different bugtracking software for you. All of them are absolutely terrible to use. The sooner all FOSS migrates to Gitlab the better - we're stifling FOSS' progress by using tools majorly out-of-date.
    - ignaloidas 7y ago
      >How do you deal with continuous integrations and making sure things like CLAs are signed? How does issue tracking integrate there? The same way that you do that on github: many mailing lists can send webhooks on email received, and then it's up to your CI and CLA bot to respond to that email accordingly. > You mean you don't create a fork by cloning the repository onto your PC when using e-mail? I mean that you must open up a browser, open the main project repository, click fork, and wait for a minute for the forking to complete so that I would be able to push to my github fork now. I don't need to waste my time doing such stuff when using email. > Or that somehow `git send-email` is harder than `git push`? `git send-email` is just as easy as `git push` and I see additional benefit in it integrates you message to maintainers too, not having to write it separately > I'd gladly remove `send-email` from git Good luck trying to do that, Linux, arguably the biggest and the most important project out there, the one for which git was originally created, still happily lives using email and mailing lists. >for it's negative effects on FOSS, it's clearly making people think it's somehow nice to use or start using. Excuse me, WTF? How is it negative exactly? It lets FOSS be vendor independent, it allows big projects to exist. Linux, PostgreSQL, *BSD, even git itself, uses email to collaborate. Clearly there is no negative impact as these projects are so successful. > All of them are absolutely terrible to use. My experience is quite the contrary. While the interfaces aren't necessarily the most beautiful thing you've seen, they have all the most common actions easily reachable. Sending bug reports to Mozzila, PostgreSQL, etc. was a good experience for me. > The sooner all FOSS migrates to Gitlab the better. Have you've even read the first comment of this thread? It is asking about distributed git. All of the FOSS migrating to Gitlab is a highly negative thing in my opinion. Firstly it doesn't leave space for using email, which a lot of big projects have accustomed to using, and migrating to another workflow would be a massive burden, and could discourage old contributors from contributing. Secondly, that puts all of the FOSS projects in one basket, making them more vulnerable for intervention. If <nation> wanted to deny access of FOSS projects for <another-nation>, it would just have to exercise power on Gitlab, which could fly under the radar of mainstream media, while if it was hosted on plethora of platforms <nation> would have to exercise power on all of those, which definitely couldn't go unnoticed. Gitlab and github issue tracking isn't even that good. Many bigger projects use many states of bugs, like confirmed, in_progress, duplicate, etc. Github and gitlab just have open/closed, and that isn't good. If you want to find some bug to work on, it is a lot easier to filter on confirmed, than to look through the open bugs to find one that is confirmed, isn't being worked on by someone else, and isn't a duplicate of a bug that someone else is working on. All that Github and Gitlab bug tracker has is pretty UI, which doesn't mean good UX. >we're stifling FOSS' progress by using tools majorly out-of-date. The fact that those tools were created a long time ago, doesn't mean that they just stayed in those years. Tools are constantly being worked on. Linux was started in 1990s. Is it majorly out-of-date? I wouldn't say so. If it is, why are we all using it?

Avamander 7y ago

Mailings lists (and e-mail as such) are seriously cumbersome to use as a way to send contributions and even more so when you want to track bugs. Every email archive software also looks like it was made in the 80s and is disgusting, slow and unreasonably difficult to use and also lacks any kind of organizational features that issue trackers have. It is absolutely not "fine", it's borderline tolerable at best.

ignaloidas 7y ago
So you are saying that sending an e-mail is seriously cumbersome? Excuse me, but for me it is a lot more steps from local edit to a contribution using Github. For Github I (1) have to create a fork (2) set it as a remote in my local copy, or if I forgot how to do it, (2.1) pull another one and copy my changes to it, (3) push my changes to my fork, (4) open a pull request in Github, which takes 3 context switches. Meanwhile for email I (1) look at README to find the email of development mailing list, (2) set it up for git send-email(https://git-send-email.io/ https://git-send-email.io/) and (3) send my patches upstream, all with me staying withing my editor with an integrated terminal. No need to open up gmail or thunderbird, or even mutt or aerc. Contribution workflow is a lot more streamlined. If you don't like mailing lists for issue tracking, there is git-bug or plethora of different bugtracking software for you.
- Avamander 7y ago
  Now you described only sending one patch. How do you deal with continuous integrations and making sure things like CLAs are signed? How does issue tracking integrate there? Answer: it doesn't, it's all a major PITA to arrange. > For Github I (1) have to create a fork (2) set it as a remote in my local copy, or if I forgot how to do it, (2.1) pull another one and copy my changes to it, (3) push my changes to my fork, (4) open a pull request in Github, which takes 3 context switches. You mean you don't create a fork by cloning the repository onto your PC when using e-mail? Or that somehow `git send-email` is harder than `git push`? I disagree having done both. I'd gladly remove `send-email` from git for it's negative effects on FOSS, it's clearly making people think it's somehow nice to use or start using. > there is git-bug or plethora of different bugtracking software for you. All of them are absolutely terrible to use. The sooner all FOSS migrates to Gitlab the better - we're stifling FOSS' progress by using tools majorly out-of-date.
  - ignaloidas 7y ago
    >How do you deal with continuous integrations and making sure things like CLAs are signed? How does issue tracking integrate there? The same way that you do that on github: many mailing lists can send webhooks on email received, and then it's up to your CI and CLA bot to respond to that email accordingly. > You mean you don't create a fork by cloning the repository onto your PC when using e-mail? I mean that you must open up a browser, open the main project repository, click fork, and wait for a minute for the forking to complete so that I would be able to push to my github fork now. I don't need to waste my time doing such stuff when using email. > Or that somehow `git send-email` is harder than `git push`? `git send-email` is just as easy as `git push` and I see additional benefit in it integrates you message to maintainers too, not having to write it separately > I'd gladly remove `send-email` from git Good luck trying to do that, Linux, arguably the biggest and the most important project out there, the one for which git was originally created, still happily lives using email and mailing lists. >for it's negative effects on FOSS, it's clearly making people think it's somehow nice to use or start using. Excuse me, WTF? How is it negative exactly? It lets FOSS be vendor independent, it allows big projects to exist. Linux, PostgreSQL, *BSD, even git itself, uses email to collaborate. Clearly there is no negative impact as these projects are so successful. > All of them are absolutely terrible to use. My experience is quite the contrary. While the interfaces aren't necessarily the most beautiful thing you've seen, they have all the most common actions easily reachable. Sending bug reports to Mozzila, PostgreSQL, etc. was a good experience for me. > The sooner all FOSS migrates to Gitlab the better. Have you've even read the first comment of this thread? It is asking about distributed git. All of the FOSS migrating to Gitlab is a highly negative thing in my opinion. Firstly it doesn't leave space for using email, which a lot of big projects have accustomed to using, and migrating to another workflow would be a massive burden, and could discourage old contributors from contributing. Secondly, that puts all of the FOSS projects in one basket, making them more vulnerable for intervention. If <nation> wanted to deny access of FOSS projects for <another-nation>, it would just have to exercise power on Gitlab, which could fly under the radar of mainstream media, while if it was hosted on plethora of platforms <nation> would have to exercise power on all of those, which definitely couldn't go unnoticed. Gitlab and github issue tracking isn't even that good. Many bigger projects use many states of bugs, like confirmed, in_progress, duplicate, etc. Github and gitlab just have open/closed, and that isn't good. If you want to find some bug to work on, it is a lot easier to filter on confirmed, than to look through the open bugs to find one that is confirmed, isn't being worked on by someone else, and isn't a duplicate of a bug that someone else is working on. All that Github and Gitlab bug tracker has is pretty UI, which doesn't mean good UX. >we're stifling FOSS' progress by using tools majorly out-of-date. The fact that those tools were created a long time ago, doesn't mean that they just stayed in those years. Tools are constantly being worked on. Linux was started in 1990s. Is it majorly out-of-date? I wouldn't say so. If it is, why are we all using it?