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

July 2025

S M T W T F S
  123 45
6789101112
1314 1516171819
2021 2223242526
2728293031  

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Tuesday, 29 July 2025 01:18 am
Powered by Dreamwidth Studios