Is this the official libb64 repository?

[mikedld]

Among the dozens of libb64 repositories here on GitHub (including mine), varying in their modification and attribution levels, I've stumbled upon https://github.com/brodybits/libb64-encode/commit/92aaefabdba9d8f190a36f70f1fe5ac0e565aed3 which seems to assume that @gorb314 is in fact Chris Venter, making this repository here (not taking SourceForge one into account) the actual source of truth. I hereby have a few of questions:

1. Are you in fact Chris Venter and is this in fact the official libb64 repository?
2. If so, are you planning on maintaining the library in any way going forward, including (but not limited to) reviewing/accepting PRs?

The dissonance between other libb64 repositories is proof that we are in need of some kind of coordination.

[gorb314]

Hi Mike,

nice to meet you. Happy new year!

To your question: yes, I am gorb314 / Chris Venter and yes I am the original author of the libb64 library.

I originally wrote it because I was working at a company that needed such a library, and I needed something lightweight and acceptably open source. So I decided to write it in my spare time and release it, then told my boss that we could use it. I figured someone else might be able to use it too.

The library is pretty simple, as I can imagine you know. Yes, there are some weird corner cases that may trip the library up, and the Visual Studio 6 project is hopelessly out of date. However, I think most people have found a way around this without any official support, given that this is not really owned by anyone - I explicitly placed it in the public domain and do not maintain any kind of ownership to the code. This is not the linux kernel or anything like that!

However if you feel there is a need for proper coordination, then I would not mind someone taking up the reigns and doing the right thing. Are you volunteering for this job?

Thanks, Chris

-- Friends may come and go. But two hundred pounds is always two hundred pounds. Henry Rollins

On Mon, Jan 6, 2020 at 7:16 AM Mike Gelfand notifications@github.com wrote:

Among the dozens of libb64 repositories here on GitHub (including mine), varying in their modification and attribution levels, I've stumbled upon brodybits/libb64-encode@92aaefa https://github.com/brodybits/libb64-encode/commit/92aaefabdba9d8f190a36f70f1fe5ac0e565aed3 which seems to assume that @gorb314 https://github.com/gorb314 is in fact Chris Venter, making this repository here (not taking SourceForge one into account) the actual source of truth. I hereby have a few of questions:

1. Are you in fact Chris Venter and is this in fact the official libb64 repository?
2. If so, are you planning on maintaining the library in any way going forward, including (but not limited to) reviewing/accepting PRs?

The dissonance between other libb64 repositories is proof that we are in need of some kind of coordination.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorb314/libb64/issues/1?email_source=notifications&email_token=AAGNO2A6H44Y322F5EJI7JTQ4NDOJA5CNFSM4KDFWYB2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IEH55RQ, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGNO2CV2DHYR3KJULDQNULQ4NDOJANCNFSM4KDFWYBQ .

[mikedld]

Nice to meet you as well, Chris.

The problem as I see it here is the lack of any kind of "upsteam". If someone is there to accept the patches and new versions keep coming out every now and then, everything is good. But what happens now is that we have a number of forks where people are making the same changes over and over again, with little twists to one or another side based on their preferences and level of coding experience, instead of making those changes once and letting everyone benefit from them.

This could in part be since SourceForge project is still there but appears dead as issues/patches present there aren't being accepted; if you were to point people from SF to GH that would at least lead to people forking this repository instead of creating "unofficial SF mirrors", which would in turn make it easier to track the changes other people are doing, and consider them for inclusion on your own, if active PR acceptance is not planned.

Over the past years a few fixes have accumulated that I think would be nice to have in an official wrapping. Believe it or not, some systems/distributions provide a libb64 package now (including Gentoo and FreeBSD that I know of), hopefully not solely because of Transmission using it, and I would naturally like to depend on those packages instead of (or in addition to) bundling the library with the particular software to make it easier for maintainers to fix issues. The version of libb64 that Transmission bundles right now is actually patched, making its behavior a bit different from that of the packaged library, which is a concern for me.

I don't expect there to be a lot of activity here, given that the library is quite simple indeed and I'd say has proven to be stable for a number of projects using it. My track record isn't that great when it comes to managing things, but if no one else is willing (including you) I guess I could give it a try.

[mikedld]

Alternative is to point people from SF to one of the forks that appears to be [more] active, e.g. https://github.com/libb64/libb64, and let package maintainers peek it up instead of an outdated version this one appears to be right now.

[brodycj]

Hi I just found this official libb64 repository after years of maintaining my own disconnected fork of the cencode function and would love it if we could find a way to converge down to an officially maintained repository that others could fork in the future. I would love to open an issue in https://github.com/libb64/libb64 but it only allows PRs. Aargh!