1. 9
    1. 1

      If you’re on OpenBSD and this is biting you, I guess the fix would be to patch the port to push it up to at least 1.8.1 which has this fixed upstream. Or, you can just build it yourself and use that version instead.

      Has Rachel submitted a patch to the ports? Seems like she hasn’t, and I don’t blame her. The OpenBSD project sets a high bar for contribution, in means of tolerance towards user-hostile tooling. Contributing to open source can be far more tiresome than fixing it for yourself, and I found OpenBSD even more taxing than other projects.

      It makes me sad as this phenomenon is one of the reasons classical open source made by the people for the people is dying, and large companies take over opensource with their PR-open sourced projects.

      1. 1

        Has Rachel submitted a patch to the ports? Seems like she hasn’t, and I don’t blame her.

        Don’t hold your breath. (That said, I’d happily to contribute to most projects, and OpenBSD’s process would require significantly more effort on my part.)

        1. 1

          Asking you and the parent comment.

          What is it about the OpenBSD process that you feel makes it so hard?

          It’s a bit harder than sending a PR on GitHub. And the quality expectations are high, so you need to read the docs and get an understanding of the process.

          But when I contributed some things to OpenBSD ports (updating versions in an existing port and it’s deps) I found everyone I interacted with to be very helpful, even when I was making dumb mistakes.

          1. 2
            • no easily searchable bug database with publicly available status discussion to know if anybody is working on it, what work and maybe dead-ends were hit. No, a mailing list is not a proper substitute for this.
            • everything is done in email with arcane formatting requirements.
            • the whole tooling is arcane to contemporary users. (CVS, specifically formatted email, etc)

            I have done my BSD contributions in the past when I had more time and willingness to go the extra mile for the sake of others. I no longer wish to use painful tools and workflows for the sake of others’ resistance to change. It is an extra burden.

            Don’t get me wrong, this is not only about OpenBSD. The same goes for Fedora for example, they have their own arcane tooling and processes, and so do lots of other projects. They have tools and documentation, but lots of docs are outdated, and for those not being constantly in the treadmill these are a lot of extra research and work which is “helped” by outdated docs etc. and it is a giant hill to climb to publish an update of a version number and re-run of the build script.

            1. 1

              Thanks, this is a good answer.

              It was nice to see Debian move to a Gitlab instance, and nice to see FreeBSD is finally moving to Git.

              But I suspect not much is going to change with OpenBSD, though maybe Got will improve things at some point.

        2. 1

          Oh. Now this is totally a different reason from what I was thinking about. (I personally don’t agree to her on this one. Still I don’t blame her, even if her different “political”/cultural stance would be her sole reason. People must accept that this is also a freedom of open source users.)

          Recently I have made up my mind to once again contribute more than I did in the past few years, and while my PRs were accepted, some still didn’t make it to a release, and the project has no testing release branch (which I also understand for a tiny project), thus compiling your own fork makes sense even this way. And this way contributing stuff stuff often gets left behind in the daily grind. On the other hand some other tiny contributions were accepted with such warmth and so quick response time that it felt really good.