14 ms·

Here's an idea, somewhat tangential - modernize the freaking dev tools. It frustrates me that these projects still use mailing lists and have no sane UI to trac

Here's an idea, somewhat tangential - modernize the freaking dev tools. It frustrates me that these projects still use mailing lists and have no sane UI to track issues, submit PRs like Github, or maybe a Gitter channel for ad-hoc chat/questions. It would bring a lot more attention to whats going on and let the community start policing bad behavior by maintainers. He even mentions how contributors will often not modify their PRs according to maintainer and view code review as a rubber-stamp. I rarely see this happening on Github - because PRs are a product feature. They've already spent time designing the feature just right to convey what the contract of a PR is, so the linux kernel maintainers don't have to. The README would also have a giant "Contributors" heading outlining the guidelines that everyone can see. This is really a UI problem. But projects from Linux/Apache consistently refuse to acknowledge its importance.

tytso 10y ago
There are tools that get used by maintainers. For example, patchwork is used by many subsystem trees to track patches and the discussion around them. And those developers and maintainers who fix bugs (and who are getting paid for it, as opposed to bugs that get fixed for free), do generally use some bug tracking system, but it tends to be one specific for the production kernel tree or product tree. Yes, that means that there is some duplication of effort, but the fact of the matter is that people don't use the upstream kernel tree directly for any product or production service, so having a bugzilla tree for that only makes sense if you have a large team of people who are exclusively working on upstream --- and often times, that's not the case.
stonogo 10y ago
I know this is not a popular statement on Hacker News, but this development model existed for dozens of years before Github, and it will persist long after Github is gone. The entire concept of a 'pull request' is a very recent fad, one with many drawbacks -- most of which have been enumerated by the very development teams you're insisting should adopt PRs. The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have. Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute.
- Ajedi32 10y ago
  > The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have. Why? Can't you just set up a GitLab instance and require that PRs should be submitted through that system? > Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute. So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.
  - rhizome 10y ago
    Not terribly difficult to describe, sure.
    - Ajedi32 10y ago
      GitLab has a well documented API: https://docs.gitlab.com/ee/api/merge_requests.html#create-mr https://docs.gitlab.com/ee/api/merge_requests.html#create-mr You could probably do the whole thing with like 50-80 lines of bash.
      - sytse 10y ago
        That is a great idea. If we need to add features to GitLab to do this please let us know.
        Ajedi32 10y ago
        GitLab already has a built-in way to reply to comments by email, right? I wonder how difficult it'd be to make "submit PR by email" part of GitLab itself. Personally I probably wouldn't use that feature, as I'm already very comfortable with the Web UI, but judging from some of the other comments in this thread it sounds like some people might...
ma2rten 10y ago
Linus disagrees. https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546...
- dsp1234 10y ago
  4 and a half years is a lot of time. Taking that comment at face value means accepting the assumption that Github's PR UI hasn't changed in that entire time.
  - TAForObvReasons 10y ago
    You very clearly didn't read the actual linked comment. > github throws away all the relevant information, like having even a valid email address for the person asking me to pull. Github explicit decided to eschew valid email addresses: https://help.github.com/articles/keeping-your-email-address-private/ https://help.github.com/articles/keeping-your-email-address-... He explains in a later comment: https://github.com/torvalds/linux/pull/17#issuecomment-5659933 https://github.com/torvalds/linux/pull/17#issuecomment-56599... > real explanation, proper email addresses, proper shortlog, and proper diffstat. > no sane word-wrap of the long description you type: github commit messages tend to be (if they have any description at all) one long unreadable line. I don't know if github supports editing like that but by default it does one long line. Related pain point: when I want to type out something in a fenced code block, it's a pain to have to switch back and forth. I do wish the editor forced a monospace font.
    - Ajedi32 10y ago
      > Github explicit decided to eschew valid email addresses No, that's a choice individual users make. As you can see from that help article, they have to explicitly set their git client to use an invalid email address if they want that. GitHub cannot and does not alter the email addresses contained in pushed commits. (Doing so would change the commit hash, making it an entirely different commit.) > He explains in a later comment Seems like the only thing missing is a way to wrap commit messages to 80 chars. Everything else is the fault of the person sending the PR, not GitHub. Also it only applies to commits _created_ from the GitHub Web UI. I don't know about you, but I only do that for extremely trivial changes.
chriswarbo 10y ago
> It frustrates me that these projects still use mailing lists and have no sane UI to track issues, submit PRs like Github, or maybe a Gitter channel for ad-hoc chat/questions. I'm not a kernel dev, but I have to ask: what's wrong with mailing lists? Unlike your examples of GitHub and Gitter, they're unencumbered FOSS; this is very important for the Linux kernel, since Linus et al. invented git specifically to remove BitKeeper's proprietary sword of damocles from hanging over the kernel. GitHub is basically BitKeeper 2.0. UI-wise, each dev is free to access their mail however they like. It also has advantages of being federated, accessible offline, easy to write bots for, etc. Presumably some devs have nice UI and automation scripts for their particular workflows; it would certainly be nice if links to such things were collected somewhere, but I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen. As for GitHub pull requests, I've never actually seen the appeal. Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`? I agree that bug tracking seems to be a bit lacking. I've dabbled with things like bugseverywhere, but so far nothing's managed to stick :(
- RhodesianHunter 10y ago
  Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; Because noone wants to see or deal with your cruft, or that of the thousands of other people also contributing to a large project. Keep it in your own private space until it's accepted as being actually part of the project.
  - chriswarbo 10y ago
    > Keep it in your own private space until it's accepted as being actually part of the project. I don't understand; is a clone on my laptop not my own private space?
  - marssaxman 10y ago
    I'm not sure what you're talking about here. I don't have commit access to their repository; I just have my local clone. In normal usage, should I want to try fixing a bug or making some other improvement, I'd simply hack on the local repository until I felt satisfied with the change, then mail the diff to some maintainer for review. What "cruft" is there for anyone to see? With the pull-request model, there's a lot of Github-specific folderol necessary to accomplish the same task. Perhaps the pull request process offers some significant benefit for the maintainers, which I haven't been able to see, but whatever it is, it must be weighed against the fact that the complexity of the pull-request process creates a barrier to entry. I can think of two situations where I had enough interest in contributing to a project that I downloaded the code and diagnosed the issue that was bugging me, but gave up when it started to look like it was going to take an hour of extra github hoop-jumping and potentially days of review and testing process just to share my one-line fix. If I'd already been a participant in those projects, dealing with the process might not have been such an issue; but as an outsider, the pull request work flow is a pretty clear "get serious about joining our project, or go away" message. So, I went away. Perhaps those projects will fix those bugs themselves, eventually.
bcoca 10y ago
As an OSS maintainer that is currently struggling with this I can tell you the solutions are not that simple: - We use several mailing lists (like a forum its good for async communication) - We have several IRC channels for immediate feedback - We don't have glitters/slack/discord/etc because more avenues of communication actually makes us scale less - reviews are not rubber stamps - we use github to host our repos and as a ticketing system - we have developer docs (sometimes they do lag or are incomplete) We still have much larger backlog than we want and plenty of people mad/exasperated on our scale and turnaround for versions and features. I don't think UI is an issue as much as other factors, many other things will affect the project. As for the communication channels, a good community actually offloads work from maintainers. As users get to know/use the project and pay attention to the channels, they end up doing a lot of support and freeing the maintainers to work on the code. To get to this point the maintainers have to have put in the work and have helped the community gain the knowledge needed. That said, it is not a license for maintainers to check out, just a good way to share the burden. Github has a huge community around it, but it's ticketing system is limited and not great for big projects, they are working hard to fix this, releasing many updates and features this last year that have made our lives easier, but it is still an issue (see "open letters" from last year for details). Much time is spent dealing with insufficient data from users/contributors or just plain unreasonable requests: "soo this does not work in AIX 4.1 (current is 7.2?) with custom built python 2.4 from which you removed core libraries and a non POSIX custom built grep? no .. we don't have tests for this". A good ticketing system can help, but it will not solve the issue (skynet might, but that might be too drastic). A factor is maintainer 'control', it is hard to let others 'raise your baby', specially as their vision might diverge from yours. Even w/o sparking flamewars there is a constant time sink in discussion of ideas, feature set and roadmaps. Design by comity or popularity does not normally lead to good results either and IME sparks more flamewars than it avoids. Another is code quality, most projects start w/o a big test infrastructure (one guy really doesn't need much), once you have hundreds of contributors you struggle to get proper linting, testing, access to resources, etc. No one writes perfect code, no one can perfectly review code, more code == more bugs == slower turnaround. Reviews are a bottleneck .. yet they are the primary guarantee for code and interface quality. Rubber stamps will create more work for you in the end as you'll spend multiple cycles fixing bad code , tests can only help you so much so much of the burden falls on the maintainers. Tests are code too! People forget this and put little/no review into tests or have many trivial tests (check that setters/getters actually work...) to get 100% code coverage. Code coverage is not a goal, code quality is. The point here is that test are also a lot of work, specially getting them 'right' for your project, what this means is also fodder for flame wars. Not having good testing, also creates more work as more bugs will get into the code. Most contributors won't maintain their code, many in OSS will contribute code and then disappear, any problem with it has to be dealt with by either the maintainers or someone else in the community that might also 'contribute and evaporate'. As code bases grow and features are added, the maintainers increase their burden. This is alleviated by increasing maintainer numbers, but that is always trailing the burden by a lot. Adding too many maintainers, it gets to a point that adding maintainers creates more burden, coordination, design decisions, knowledge sharing, etc ... team management in general. ... I'm going to stop now, I could probably write many pages on this but I think the above is enough to show that this is not easily solved by using a few new tools or UI, docs do help, but that is another maintainer burden. Maintainers normally just use what 'works for them' and most will look to improve the process. We all get many suggestions, it is impractical to try them all and the 'latest trend' dies down faster than the time it takes one to shift the workflow to try it. The few times I've been able to do so, it is either not an improvement or just not enough of one to justify the effort of switching the workflow. If someone has a way to make managing big|popular OSS projects simple and seamless ... LET ME KNOW!
ar15saveslives 10y ago
Great example of what you're talking about: https://github.com/FFmpeg/FFmpeg/pull/153 https://github.com/FFmpeg/FFmpeg/pull/153
- bcoca 10y ago
  yes, many times we need to work 'around' the tools as they do not do what we want and cannot disable to avoid confusion: https://github.com/ansible/ansible/releases https://github.com/ansible/ansible/releases

tytso 10y ago

There are tools that get used by maintainers. For example, patchwork is used by many subsystem trees to track patches and the discussion around them. And those developers and maintainers who fix bugs (and who are getting paid for it, as opposed to bugs that get fixed for free), do generally use some bug tracking system, but it tends to be one specific for the production kernel tree or product tree. Yes, that means that there is some duplication of effort, but the fact of the matter is that people don't use the upstream kernel tree directly for any product or production service, so having a bugzilla tree for that only makes sense if you have a large team of people who are exclusively working on upstream --- and often times, that's not the case.

stonogo 10y ago

I know this is not a popular statement on Hacker News, but this development model existed for dozens of years before Github, and it will persist long after Github is gone. The entire concept of a 'pull request' is a very recent fad, one with many drawbacks -- most of which have been enumerated by the very development teams you're insisting should adopt PRs. The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have. Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute.

Ajedi32 10y ago
> The largest single problem with PRs is the implication that we all have git repositories with a shared authentication mechanism. It's very difficult to enforce this sort of thing in a developer environment as diverse as these large projects have. Why? Can't you just set up a GitLab instance and require that PRs should be submitted through that system? > Sending patches via SMTP is arguably the most inclusive possible development model and I really value its availability in projects to which I contribute. So just keep that option available for those who want it. Set up a bot that opens PRs automatically for any patches it receives by email. Doesn't seem like that'd be terribly difficult.
- rhizome 10y ago
  Not terribly difficult to describe, sure.
  - Ajedi32 10y ago
    GitLab has a well documented API: https://docs.gitlab.com/ee/api/merge_requests.html#create-mr https://docs.gitlab.com/ee/api/merge_requests.html#create-mr You could probably do the whole thing with like 50-80 lines of bash.
    - sytse 10y ago
      That is a great idea. If we need to add features to GitLab to do this please let us know.
      - Ajedi32 10y ago
        GitLab already has a built-in way to reply to comments by email, right? I wonder how difficult it'd be to make "submit PR by email" part of GitLab itself. Personally I probably wouldn't use that feature, as I'm already very comfortable with the Web UI, but judging from some of the other comments in this thread it sounds like some people might...

ma2rten 10y ago

Linus disagrees. https://github.com/torvalds/linux/pull/17#issuecomment-5654674 https://github.com/torvalds/linux/pull/17#issuecomment-56546...

dsp1234 10y ago
4 and a half years is a lot of time. Taking that comment at face value means accepting the assumption that Github's PR UI hasn't changed in that entire time.
- TAForObvReasons 10y ago
  You very clearly didn't read the actual linked comment. > github throws away all the relevant information, like having even a valid email address for the person asking me to pull. Github explicit decided to eschew valid email addresses: https://help.github.com/articles/keeping-your-email-address-private/ https://help.github.com/articles/keeping-your-email-address-... He explains in a later comment: https://github.com/torvalds/linux/pull/17#issuecomment-5659933 https://github.com/torvalds/linux/pull/17#issuecomment-56599... > real explanation, proper email addresses, proper shortlog, and proper diffstat. > no sane word-wrap of the long description you type: github commit messages tend to be (if they have any description at all) one long unreadable line. I don't know if github supports editing like that but by default it does one long line. Related pain point: when I want to type out something in a fenced code block, it's a pain to have to switch back and forth. I do wish the editor forced a monospace font.
  - Ajedi32 10y ago
    > Github explicit decided to eschew valid email addresses No, that's a choice individual users make. As you can see from that help article, they have to explicitly set their git client to use an invalid email address if they want that. GitHub cannot and does not alter the email addresses contained in pushed commits. (Doing so would change the commit hash, making it an entirely different commit.) > He explains in a later comment Seems like the only thing missing is a way to wrap commit messages to 80 chars. Everything else is the fault of the person sending the PR, not GitHub. Also it only applies to commits _created_ from the GitHub Web UI. I don't know about you, but I only do that for extremely trivial changes.

chriswarbo 10y ago

> It frustrates me that these projects still use mailing lists and have no sane UI to track issues, submit PRs like Github, or maybe a Gitter channel for ad-hoc chat/questions. I'm not a kernel dev, but I have to ask: what's wrong with mailing lists? Unlike your examples of GitHub and Gitter, they're unencumbered FOSS; this is very important for the Linux kernel, since Linus et al. invented git specifically to remove BitKeeper's proprietary sword of damocles from hanging over the kernel. GitHub is basically BitKeeper 2.0. UI-wise, each dev is free to access their mail however they like. It also has advantages of being federated, accessible offline, easy to write bots for, etc. Presumably some devs have nice UI and automation scripts for their particular workflows; it would certainly be nice if links to such things were collected somewhere, but I don't see any dichotomy between using email and having a nice UI. I certainly find my email UI (Emacs + Mu4e) far nicer than any Web site I've ever seen. As for GitHub pull requests, I've never actually seen the appeal. Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; when I could instead run `git send-email`? I agree that bug tracking seems to be a bit lacking. I've dabbled with things like bugseverywhere, but so far nothing's managed to stick :(

RhodesianHunter 10y ago
Once I've cloned a repo and made a change, why do I then have to "fork" the repo, add a new remote to my clone, push the changes then open a pull request; Because noone wants to see or deal with your cruft, or that of the thousands of other people also contributing to a large project. Keep it in your own private space until it's accepted as being actually part of the project.
- chriswarbo 10y ago
  > Keep it in your own private space until it's accepted as being actually part of the project. I don't understand; is a clone on my laptop not my own private space?
- marssaxman 10y ago
  I'm not sure what you're talking about here. I don't have commit access to their repository; I just have my local clone. In normal usage, should I want to try fixing a bug or making some other improvement, I'd simply hack on the local repository until I felt satisfied with the change, then mail the diff to some maintainer for review. What "cruft" is there for anyone to see? With the pull-request model, there's a lot of Github-specific folderol necessary to accomplish the same task. Perhaps the pull request process offers some significant benefit for the maintainers, which I haven't been able to see, but whatever it is, it must be weighed against the fact that the complexity of the pull-request process creates a barrier to entry. I can think of two situations where I had enough interest in contributing to a project that I downloaded the code and diagnosed the issue that was bugging me, but gave up when it started to look like it was going to take an hour of extra github hoop-jumping and potentially days of review and testing process just to share my one-line fix. If I'd already been a participant in those projects, dealing with the process might not have been such an issue; but as an outsider, the pull request work flow is a pretty clear "get serious about joining our project, or go away" message. So, I went away. Perhaps those projects will fix those bugs themselves, eventually.

bcoca 10y ago

As an OSS maintainer that is currently struggling with this I can tell you the solutions are not that simple: - We use several mailing lists (like a forum its good for async communication) - We have several IRC channels for immediate feedback - We don't have glitters/slack/discord/etc because more avenues of communication actually makes us scale less - reviews are not rubber stamps - we use github to host our repos and as a ticketing system - we have developer docs (sometimes they do lag or are incomplete) We still have much larger backlog than we want and plenty of people mad/exasperated on our scale and turnaround for versions and features. I don't think UI is an issue as much as other factors, many other things will affect the project. As for the communication channels, a good community actually offloads work from maintainers. As users get to know/use the project and pay attention to the channels, they end up doing a lot of support and freeing the maintainers to work on the code. To get to this point the maintainers have to have put in the work and have helped the community gain the knowledge needed. That said, it is not a license for maintainers to check out, just a good way to share the burden. Github has a huge community around it, but it's ticketing system is limited and not great for big projects, they are working hard to fix this, releasing many updates and features this last year that have made our lives easier, but it is still an issue (see "open letters" from last year for details). Much time is spent dealing with insufficient data from users/contributors or just plain unreasonable requests: "soo this does not work in AIX 4.1 (current is 7.2?) with custom built python 2.4 from which you removed core libraries and a non POSIX custom built grep? no .. we don't have tests for this". A good ticketing system can help, but it will not solve the issue (skynet might, but that might be too drastic). A factor is maintainer 'control', it is hard to let others 'raise your baby', specially as their vision might diverge from yours. Even w/o sparking flamewars there is a constant time sink in discussion of ideas, feature set and roadmaps. Design by comity or popularity does not normally lead to good results either and IME sparks more flamewars than it avoids. Another is code quality, most projects start w/o a big test infrastructure (one guy really doesn't need much), once you have hundreds of contributors you struggle to get proper linting, testing, access to resources, etc. No one writes perfect code, no one can perfectly review code, more code == more bugs == slower turnaround. Reviews are a bottleneck .. yet they are the primary guarantee for code and interface quality. Rubber stamps will create more work for you in the end as you'll spend multiple cycles fixing bad code , tests can only help you so much so much of the burden falls on the maintainers. Tests are code too! People forget this and put little/no review into tests or have many trivial tests (check that setters/getters actually work...) to get 100% code coverage. Code coverage is not a goal, code quality is. The point here is that test are also a lot of work, specially getting them 'right' for your project, what this means is also fodder for flame wars. Not having good testing, also creates more work as more bugs will get into the code. Most contributors won't maintain their code, many in OSS will contribute code and then disappear, any problem with it has to be dealt with by either the maintainers or someone else in the community that might also 'contribute and evaporate'. As code bases grow and features are added, the maintainers increase their burden. This is alleviated by increasing maintainer numbers, but that is always trailing the burden by a lot. Adding too many maintainers, it gets to a point that adding maintainers creates more burden, coordination, design decisions, knowledge sharing, etc ... team management in general. ... I'm going to stop now, I could probably write many pages on this but I think the above is enough to show that this is not easily solved by using a few new tools or UI, docs do help, but that is another maintainer burden. Maintainers normally just use what 'works for them' and most will look to improve the process. We all get many suggestions, it is impractical to try them all and the 'latest trend' dies down faster than the time it takes one to shift the workflow to try it. The few times I've been able to do so, it is either not an improvement or just not enough of one to justify the effort of switching the workflow. If someone has a way to make managing big|popular OSS projects simple and seamless ... LET ME KNOW!

ar15saveslives 10y ago

Great example of what you're talking about: https://github.com/FFmpeg/FFmpeg/pull/153 https://github.com/FFmpeg/FFmpeg/pull/153

bcoca 10y ago
yes, many times we need to work 'around' the tools as they do not do what we want and cannot disable to avoid confusion: https://github.com/ansible/ansible/releases https://github.com/ansible/ansible/releases