“The shortness of MIT and BSD [licenses] are reassuring only until you actually try to understand them, and find you need a decoder ring. The terms are actually dangerous if you read them without knowing you need that decoder ring.”

Okay, now I know at least that I need a decoder ring…


The hardest problem in is tracking down missing maintainers.

Today I invested 4½ hours to increase the bash completion for tig by a factor of about 1000: github.com/jonas/tig/pull/960

I will not participate in this year, although contributing to and is my day job. First, I already have enough t-shirts. But second, the ecosystem I use on a daily basis is mostly made up of projects that use GitLab, or BitBucket, or sr.ht, or Fossil, or sending patches by mail, or GNU Savannah, or (good grief!) even SourceForge. I think only two of the projects I contributed last year were on GitHub.

The world is so much bigger. Don't forget that.

can2joy –Use your car as a life-sized controller for your racing game on Linux!

(At the moment, only the following model has been tested: Volkswagen Golf Mk 6)


Upstream developers: changing your already released tarballs is an antipattern and breaks reproducabilty. We all make errors, we don't hate you for releasing a -repack1.tar.gz :)


And I wondered whether there is a correlation of "our code" projects being organised socially in a way that makes it difficult for new users to contribute, and as such "prove their worth to the community" by taking all those extra hurdles to get their contribution in. These projects would possibly also be more opposed to explicit docs or codes of conduct.

So here's an unproven hypothesis, there's probably a PhD or master's thesis hidden in there somewhere :)

Show thread

At I heard a talk today about one-time contributions to projects [1]. The main focus was what to do best to get your contribution accepted, but it also included a categorisation of projects into "our code" projects, which basically ask why your contribution is worthy enough to be accepted, and "your code" projects that ask "how can we maintain your contribution in the long term".

[1] Diary of a Drive by Coder, by James Bottomley, osseu18.sched.com/event/FxWu

When writing change logs for version control, definitely include the "why". 

When submitting patches, the reason for a change can tell the maintainers about your use case, which bugs it fixes, and also about potential regressions in other branches.

In five years, everyone can see what you did, but without an included reason, it will be lost and need to be guessed.

When hunting for bugs (e.g. via git-bisect), you'll want to know whether a commit can be reverted safely.

I guess it's time for .

I'm a mostly harmless person living in , .

My current job is working with and on , in my spare time I'm involved in @stratum0, our . Other interests include , and learning languages for fun – I'm fluent in and , can also understand and , and read a lot of other scripts to some extent. Mi ankaŭ provas studi la ​n.


chaos.social – a Fediverse instance for & by the Chaos community