Sunday, 24 November 2019

bens_dad: (Default)
On Friday I made my first git merge request to an open source project ( https://gitlab.gnome.org/GNOME/ghex/merge_requests/11 - a fix so that the 64 bit display shows the top 32bits of values). I actually wrote the patch in January, but it has taken me a while to find an active fork of the project, then a week to learn my way around gitlab to generate the merge request.

I remember when it was much simpler to fix a random bug in a Linux package; nearly twenty years ago I emailed a patch to add support for my new sound chip. Fifteen minutes after I discovered the existence of the ALSA package, my contribution was in the master source.

OK, so that was an extreme example, but emailing a patch to the development list was all you had to do to make a fix available to the world. For a project maintainer git merge requests are (likely to be) more efficient than pulling patches from a mailing-list and the project maintainers are the bottle-neck, so I see that something like a git merge request is necessary for open software development to scale.

However, from the perspective of a *casual* contributor to an open source project, mailing a patch to a mailing list was simpler. I wonder how much this hurdle keeps the pool of contributors to a project small (and restricts diversity) and whether this fixed cost on each developer makes the overall system less efficient ?

Profile

bens_dad: (Default)
bens_dad

June 2025

S M T W T F S
1234567
891011121314
1516 1718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Tuesday, 24 June 2025 06:59 pm
Powered by Dreamwidth Studios