4 ms·

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug t

by WD-42 9y ago

As someone who has attempted to contribute to the GNOME project, this makes me super happy. The current process is archaic: attaching patch files to weird bug trackers and then sorta just waiting for someone to get back to you... A proper pull request system with code review would lower the barrier of entry for contributions to these projects significantly.

therealmarv 9y ago
I don't even know how to do that although I use git every day ^^
- WD-42 9y ago
  It's not hard to create a patch from a commit, but it's very awkward and doesn't fit the "flow" I've become accustomed to while using git.
owninghome 9y ago
Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile. This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.
- mdaniel 9y ago
  For sure, and it's arguably worse when they claim "patches welcome" and then the PR sits for years without so much as a "please wait." Insult to injury when the PR is just a typo fix, or cleaning up a blatant lie in the documentation.
johannes1234321 9y ago
Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.
- chungy 9y ago
  The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead. I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.
  - deleted 9y ago
    [deleted]
- carussell 9y ago
  > a pull system is nice for drive-by contributions Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change. Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?
  - freedomben 9y ago
    To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.
    - carussell 9y ago
      I don't know what you're referring to. Not quite as laborious as what? When I mentioned things like "setting up a remote", I was specifically thinking of GitHub and GitLab's web forms. It's as exactly as involved as I outlined above.
kochthesecond 9y ago
Absolutely. There is a near hundred hour startup cost to get into helping gnome, so making this process simpler should really be prioritized.
- oAlbe 9y ago
  What do you mean? That it takes one hundred hours of experience with the code base to be able to start making contributions?
  - kochthesecond 9y ago
    Learning how to get patches submitted and accepted, and learning vala..
0d311 9y ago
I find the same issue with working on Python.

by WD-42 9y ago

therealmarv 9y ago

I don't even know how to do that although I use git every day ^^

WD-42 9y ago
It's not hard to create a patch from a commit, but it's very awkward and doesn't fit the "flow" I've become accustomed to while using git.

owninghome 9y ago

Yup, I can’t count how many times I kept bugfixes, improvements, or tweaks to myself because the submission process is too complicated and user hostile. This is honestly a problem with any submission process involving patch files. I’ve submitted a few via mailing list and I can’t express how much I dread seeing source controled this way.

mdaniel 9y ago
For sure, and it's arguably worse when they claim "patches welcome" and then the PR sits for years without so much as a "please wait." Insult to injury when the PR is just a typo fix, or cleaning up a blatant lie in the documentation.

johannes1234321 9y ago

Then you also didn't work on the kernel, the community where git came from ;) There you have to attach the patch to a weird e-mail and hope somebody picks it up. But it's true - a pull system is nice for drive-by contributions. In some projects I noticed that after being listed in GitHub (be it as mirror or primary place) the number of contributions improved, but also many low-quality contributions came in.

chungy 9y ago
The kernel’s process would be far superior to what GNOME does currently. I’ve simply not sent GNOME patches because they won’t accept them over email, and require using a wonky web interface (bugzilla) with an account to do it instead. I would really much rather to be able to just do a `git send-email` as many other projects (not just the kernel!) accept.
- deleted 9y ago
  [deleted]
carussell 9y ago
> a pull system is nice for drive-by contributions Did you mean a patch system? With a patch, you just send upstream the patch, and you're done. Pull-based syncing is good for (and was designed for) frequent collaborators. As a one-time contributor doing pull requests, after you've cloned the repo and made your changes, you have to set up some public remote so that others can pull from, push up your changes to that remote, send upstream a message that it's ready for them to pull, and make sure that remote maintains uptime until at least upstream has had an opportunity to pull, at which point you can then do whatever you want with it. It really doesn't make a lot of sense to use this workflow for anything but frequent collaborators, where the setup costs are supposed to pay off later, after you've shared your nth change. Or did you mean it's nice in the sense that increases the volume of contributors, because there's a long tail of people who are familiar with and only know how to deal in pull requests?
- freedomben 9y ago
  To be fair, a lot of the process you mention is fully automated so to the user it's just a few clicks. Not quite as laborious.
  - carussell 9y ago
    I don't know what you're referring to. Not quite as laborious as what? When I mentioned things like "setting up a remote", I was specifically thinking of GitHub and GitLab's web forms. It's as exactly as involved as I outlined above.

kochthesecond 9y ago

Absolutely. There is a near hundred hour startup cost to get into helping gnome, so making this process simpler should really be prioritized.

oAlbe 9y ago
What do you mean? That it takes one hundred hours of experience with the code base to be able to start making contributions?
- kochthesecond 9y ago
  Learning how to get patches submitted and accepted, and learning vala..

0d311 9y ago

I find the same issue with working on Python.