Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Libsixel/libsixel fork #185

Open
Kreijstal opened this issue Feb 12, 2025 · 14 comments
Open

Libsixel/libsixel fork #185

Kreijstal opened this issue Feb 12, 2025 · 14 comments

Comments

@Kreijstal
Copy link

Kreijstal commented Feb 12, 2025

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

@nirodhvana
Copy link

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

Ah dammit, so the project is dead again

@Kreijstal
Copy link
Author

is not dead unless everyone chooses it to be dead

@nirodhvana
Copy link

nirodhvana commented Feb 15, 2025

is not dead unless everyone chooses it to be dead

Are you the only maintainer now? I saw the old maintiner ranting about the api being insecure or smth.
can't the api be rewritten to be secure? Or are we just f~~kd
Also why is everyone forking repos that are dead and not even commiting anything https://github.com/YUKI2eN3e/libsixel

@akinomyoga
Copy link

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.

@nirodhvana
Copy link

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.

Wait, you're japanese? NANI??

Both the person who declared himself the new dictator and the notcurses guy seemed like the perfect recipe for another dead project. we have one man that barges in and declares himself the new owner then another who hates the concept of sixel and think's kitty is superior and then archives the repo without anymore discussion. The maintainer of mlterm @arakiken(goat btw) has contributed more than these two lol

hope @saitoha is okay considering he went missing in 2020, hope he's alive and well. Hope this new fork doesn't get the same fate.

@akinomyoga
Copy link

akinomyoga commented Feb 15, 2025

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.

@nirodhvana
Copy link

nirodhvana commented Feb 15, 2025

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.

Lol i was just memeing that all three of you @saitoha , the (i declare myself dictator) guy and you were all japanese. No racism lol sorry. Also i was memeing the whole 'NANI' part anf yes i mean it in the anime context not in some other english meaning.

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.

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.

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.

yeah i had mixed feelings when i saw the dude declaring himself the new king basically and then saying some guy was trolling for just proposing a different opinion. I dont recommend forking this new repo. We dont want another XZ utils situation on our hands

also we'd have to find someone of @saitoha and @arakiken (goat btw) 's caliber and commitment if we rely on only one person. Otherwise we need a whole team.

Who's down to maintain? [ not me ofcourse i'm a noob :( ]

also why do i see a hundred of such repos popup once these guys see a project's dead to just catch dust for the rest of eternity.
https://github.com/YUKI2eN3e/libsixel

@dankamongmen
Copy link

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
Copy link

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
Copy link
Author

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
Copy link

j4james commented Feb 16, 2025

@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
Copy link

j4james commented Feb 16, 2025

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
Copy link

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

@dankamongmen
Copy link

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants