kgio RubyGem user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <>
To: Samuel Williams <>
Cc:, Jean Boussier <>
Subject: Re: Ruby 3.3 compatible release?
Date: Mon, 28 Aug 2023 00:58:10 +0000	[thread overview]
Message-ID: <20230828005810.M622269@dcvr> (raw)
In-Reply-To: <>

Samuel Williams <> wrote:
> Hi Eric,
> Thanks for your continued effort to maintain and support this
> gem - despite how old it is - I assume you were not expecting
> it to still be in use today!
> We are trying to clean up the `io.h` interface in Ruby 3.3 and
> would like to know if there is anything we can do to help with
> a release of kgio which supports the updated interface and
> removes usage of deprecated symbols. That is because it is
> still a dependency of Unicorn, which, as of today has a market
> share of around 15% - something I hope you are really proud
> of!

Hello Samuel, please refrain from positive comments about unicorn+kgio
as they make me extremely uncomfortable.

Not only am I a shy introvert, I'm nearly certain the unintentional
popularity of these projects damaged the entire Ruby+Rack ecosystem and
set it back ~15 years in parallelism, concurrency and robustness
compared other languages+runtimes by allowing users to ignore many
types of bugs.  The negatives outweight any positives, here.

Back to the release:

Are there any other incompatibilities that may happen for Ruby 3.3
that we might have to deal with before December?  I don't want to
have to scramble another release together if we make one too soon.

Again, I'm a shy introvert and have been struggling to even make
releases+announcements for more important projects that keep me fed.

New releases also increases download counts on which puts
them in danger of MFA requirements, so I try to limit them nowadays.
MFA is more work for me to setup since I refuse to deal with corporate
Terms of Service.  I never wanted people to trust me, not just because
I'm shy but also due to the irreparable damage I've done to Ruby,
copyleft, and centralization[2].

> I believe Jean Boussier has already generously supplied a patch:
> casperisfine/kgio/commit/a04f6057a94ae8413fc6d1e7b74bfa6b9d802285.patch

> However, it does not appear to be merged or released yet.
> Anything we can do to help move things forward? Would it help
> if I resubmitted it directly using git format-patch?

I forgot about it originally because I was struggling with SSD errors
and eventual failure.  Given Jean's email was neither created with
"git format-patch" nor "git request-pull" it didn't get picked up in
later search queries, either.

Even seeing the name of that hosting platform is continual reminder
of my failures[1][2]

So please resend with "git format-patch".  Thanks.

[1] I used to tell people that "all git hosts are created equal"
    when their UI was merely Embrace+Extend.  They're now actively
    Extinguishing copyleft licenses with AI and I can't think of a way
    the Free Software community could fight it given the monetary and
    legal resources of the other side.

[2] Fwiw, I hate centralization so I created git-svn in 2006 to kill
    SVN, only to have a larger, more powerful centralized monster
    replace it.  So not only am I to blame for damaging Ruby+Rack
    with unicorn, I'm also largely to blame for the early popularity
    of said centralized platform because SVN migrants weren't ready
    for centralization-resistant workflows.  FML :<

  reply	other threads:[~2023-08-28  0:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-25  2:01 Ruby 3.3 compatible release? Samuel Williams
2023-08-28  0:58 ` Eric Wong [this message]
2023-08-28 23:34   ` Samuel Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230828005810.M622269@dcvr \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).