Libsixel/libsixel fork

[Kreijstal]

Since repo was archived all discussion was shut down
https://github.com/libsixel/libsixel
https://github.com/Kreijstal/libsixel issues and discussions are enabled

[Kreijstal]

is not dead unless everyone chooses it to be dead

[akinomyoga]

Someone should actually take over the maintenance, which means that they should process issues reported in saitoha/libsixel and libsixel/libsixel. The problem is that no one has actually taken over the maintenance so far.

When libsixel/libsixel appeared, the owner designated himself as the new maintainer by his own decision, and he was very vocal about his becoming a maintainer at #154 (and the owner has also announced it widely in SNS), although he didn't have any contributions to the project until then. It was unclear whether he would be the best person to maintain the project, and actually, there were people in the Japanese community suspecting that this could be reputation hijacking. Anyway, since no other maintainers appeared, we waited to see what came out.

What I've observed so far as a spectator is that the owner of libsixel/libsixel only added a few fixes which were rather trivial. The other things that the owner did were merging several pull requests, closing issues and retracting CVEs just because he couldn't reproduce the behavior (which I think was not good), switching the build system from autotools to meson, and creating an icon of libsixel with his taste. However, these are actually unrelated to the main codebase.

After all, the owner of libsixel/libsixel didn't seem the proper person to take over the maintenance (which could have been guessed from the initial excessive self-advertisement). In addition, in switching the building system, when there was a concern from a user, the owner immediately merged the corresponding pull request to avoid further discussion, blocked the user, and created an issue to blame the user in public for "the user's trolling" (though the user's concerns completely appeared to make sense to my eyes, which seemed to suggest needs of further discussion). In a few months, the owner disappeared quickly, and left everything to the involved people, dankamongmen (from Notcurses) and j4james (from Windows Terminal).

I think someone who is able and willing to contribute to the codebase significantly should take over the maintenance instead of someone who just popped up. To become a maintainer, one should first create significant progress in the forked repository and gauge whether one could continue to maintain the project. After that, one could show one's interest in taking over it. It is strange to declare taking over the maintenance without existing efforts and without prior estimation of whether one could continue to maintain it.

[akinomyoga]

Yes, I'm Japanese, but is that a problem? (Hmm, probably, the connotation of NANI in English would be different from the one of the original Japanese word 何... I hope you are not angry at me...) The use of Sixel in modern terminals has started in the Japanese terminal community; kmiya-culti (from RLogin), saitoha (from libsixel), and arakiken (from mlterm) are all Japanese. That would be a part of the reason that the owner of libsixel/libsixel had raised issue #154 in both English and (some broken) Japanese. In case, let me clarify that the owner of libsixel/libsixel is not native Japanese.

Please do not blame the Notcurses maintainer because I understand that the Notcurses maintainer and other people were just involved by the libsixel/libsixel owner. The libsixel/libsixel owner added famous people to advertise his repository libsixel/libsixel. Technically, the Notcurses maintainer and others are not expected to be responsible with the libsixel/libsixel repository at all, yet I appreciate the Notcurses maintainer for having taken actions, even though it's been minimal. Since the original owner---who was supposed to be responsible---disappeared, it would be understandable that the Notcurses maintainer had finally archived the repository after waiting for a long time for a new maintainer.

Honestly, libsixel/libsixel has been sketchy from the very beginning, so I'm not sure if I'd count it as another dead project. Just saitoha/libsixel became dormant, and someone tried to exploit it but failed to start it. Except that, there hasn't been any attempt to take over the maintenance (probably because of the existence of the failing libsixel/libsixel). If libsixel/libsixel were properly started by a decent person, I think it wouldn't have failed this way. We can simply find a decent maintainer to make it work.

[dankamongmen]

also i can understand that the notcurses guy was kinda dragged into this mess but i would have quit quicker had i actully been against the sixel protocol(he's free to have his opinions but i am also free to not like it) so i was just saying that it didn't help that people that were involved were not even invested into it. I apologize you both you and @dankamongmen if i was rude in any way.

i have in no way been offended, and only wish to wash my hands of this project

[dankamongmen]

Thank you for understanding. But I still think you archived the repo too quick.

if you're willing to be maintainer, i'll unarchive it and assign you

[Kreijstal]

Thank you for understanding. But I still think you archived the repo too quick.

if you're willing to be maintainer, i'll unarchive it and assign you

@j4james, wouldn't you like to maintain this? I see you like providing patch fixes and respond to issues

[j4james]

@Kreijstal Nope. I'm happy to provide patches and PRs, because that can be fun, but maintaining a project is hard work, and I'm allergic to work of any kind.

Seriously though, I think you need someone that actually depends on libsixel for their own applications, so they're incentivized to fix bugs and deal with security issues. I'm just an occasional img2sixel user, and I'm quite happy with the app as it is - bugs and all. I've only been going through the bug list now because I was curious to see if it was as bad as some people were making out to be.

[j4james]

One other point I'd like to make. If there really was anyone seriously interested in maintaining this project, they've had plenty of time to get involved. The libsixel/libsixel fork has essentially been dead for over two years now. There were a couple of recent patches from hzeller, but he expressed no interest in taking on the job of maintainer either. So while I'm disappointed that it's been archived, I can fully understand why dankamongmen has done so. It's easy enough to unarchive if a new maintainer can be found.

[dankamongmen]

i would happily unarchive it if that seemed likely to have any result beyond me getting more mails about libsixel.

[dankamongmen]

come to think of it, this thread is already more mails than i had hoped to receive about libsixel.

[saitoha]

I sincerely apologize for having been absent from this project for over five years due to personal circumstances. I am currently exploring ways to improve the situation to the best of my ability. In any case, I intend to gradually catch up on the accumulated issues and pull requests, as well as the changes that have been made in libsixel/libsixel during my absence. It will likely take some time for me to fully understand the Meson build system and GitHub Actions CI.

[dankamongmen]

good to see you back!

[eabase]

Looking forward to have a simpler and more up-to-date compile experience for the Windows builds.

[saitoha]

See the page below for the current status of our CVE handling.
#203