From: "David P. Reed" <dpreed@deepplum.com>
To: "Matt Mathis" <mattmathis@google.com>
Cc: "Dave Taht" <dave.taht@gmail.com>,
"Cake List" <cake@lists.bufferbloat.net>,
"cerowrt-devel" <cerowrt-devel@lists.bufferbloat.net>,
"bloat" <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Cake] access to cmsg from go?
Date: Wed, 23 Jun 2021 12:09:15 -0400 (EDT) [thread overview]
Message-ID: <1624464555.230819179@apps.rackspace.com> (raw)
In-Reply-To: <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
(They closed the issue on the golang link.)
I'm not a golang user. One language too many for me. It sounds like a library issue.
My suggestion would be to use the openness of open source. Generate a patchset that extends the interface properly. Don't try to "improve" what you don't like - communities like stability and backward compatibility. Explain the added semantics in documentation.
Then, maintain your fork. I don't know how the golang community works with versioning of libraries, but Python, Rust, Haskell, and NodeJS all have ways to let projects use variants of libraries.
Then, submit that patchset upstream to the golang community. Advocate for upstreaming it, and develop a community that uses the patched library. Eventually, you may be able to stop maintaining your variant toolset. Or you will develop an alternat library user base that disagrees with upstream's decisions.
(Analogy, Android's Linux Kernel vs. Linus Torvalds's. Google Android rejects to some extent Linus's crew's unwillingness to accept what Android needs as improvements.)
This is "modern open source community" practice for getting things done. Pragmatic innovations in shared codebases sometimes have to wait for the original egos to die off.
next prev parent reply other threads:[~2021-06-23 16:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-19 21:59 [Cerowrt-devel] " Dave Taht
2021-06-20 1:59 ` [Cake] " Matt Mathis
2021-06-20 20:08 ` [Cerowrt-devel] [Bloat] " Hal Murray
[not found] ` <mailman.3123.1624154360.24343.cerowrt-devel@lists.bufferbloat.net>
2021-06-23 16:09 ` David P. Reed [this message]
2021-06-23 19:29 ` [Cerowrt-devel] " Etienne Champetier
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1624464555.230819179@apps.rackspace.com \
--to=dpreed@deepplum.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cake@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
--cc=mattmathis@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox