Closed pimzand closed 2 years ago
I created a fork an ported it to Python 3. It mostly works. https://github.com/pimzand/jack
Just a quick heads up, I've alerted the original developer and he decided to do some work on jack again - after a 15 year hiatus :)
He has startet with a python3 port as well, see the port-python3-branch in https://github.com/zzarne/jack
Thanks for pointing me to that. Never expected this to happen. Happy to see it, though.
And I didn't expect anybody still working on jack, so I didn't check. Had I checked, it would have saved me a lot of work. But I don't mind; I learned a lot and I had to, since I didn't do much python in the last years.
My reason for starting to work on Jack again was Ubuntu deprecating Python 2 :)
So, how to proceed?
My Python 3 port is probably pointless. pimzand's is fine and has been improved with full musicbrainz support. I'll compare my tree to pimzand's project and send pull request for the few improvements I can contribute.
@zzarne hello! Hello everyone!
I just have one thing to say apart from that I still use and love jack
: it's more sustainable to develop a meaningful piece of software in an organization. That way the software can still be more easily maintained when the main author is not available anymore. So the jack-cli-cd-ripper organization seems to be the best place for the future of jack. I'll be very honored to hand it over to @zzarne
I completely agree. I can't be sure I'll have enough time in the future for maintaining Jack. As I have no experience running or even being in a (github) organization, I should not (and don't want to) run it. I'd be delighted to join, though. @pimzand should be invited to join, too.
Hi, just to let you know what drove me: I have been using jack for 20 years now, and I saw it coming to an end with FreeDB and Python 2 dying almost the same time. I did not want that to be the end, so I asked here if anyone was working on a Python 3 port. That would be the first step. Nobody responded so I assumed I was the single jack user in the world. I did the port, and when it worked, I could have stopped there, but I went ahead with MusicBrainz support. I did not know about gnudb then, but I did expect something like that. I was afraid though, that if any mirror site would appear, it would no longer have the authority that FreeDB had, which would make it less likely that new submissions are made the way they were. I noticed many other applications (like abcde) are using MusicBrainz merely to collect FreeDB compatible data, wasting all the detail that MusicBrainz offers. I took a look at MusicBrainz Picard and made it my goal to have jack tag files in a way that is indistinguishable from Picard. Without looking at its code. I am almost there. Meanwhile, I put a lot of stuff in that I had built in locally only, like M4A/AAC support, album artist support, better handling of multi-cd albums and more. But I did not expect to become a maintainer. In fact I removed a lot of stuff that I did not use, but other people might care for. Most of all, my repo is still under development, and there are lots of bugs in there. I might start to enter the issues known to me as github issues. Some of these issues are caused by my lack of understanding of some the original code. Anyway, I am honoured with the confidence that @zzarne has already shown. Still, there's a big chance that you guys would have done things in other ways, and I am open to that. Right now, new commits are coming slow, because I have been very busy re-tagging my music collection using MusicBrainz data.
@zzarne and @pimzand you've been invited as owners of the jack-cli-cd-ripper organization! You have full power on this organization as well as on the jack specific repository!
Thanks for the invite!
There must be at least one other user of jack. I received a support request for gnudb the day freedb was shut down.
I don't see anything wrong with your Python 3 port. Getting rid of historic helpers is right and if anybody needs additional helpers they can be added later.
I think that MusicBrainz is the way to go, too. I'd like to keep or re-add (limited) gnudb support, at least for importing rips done with jack3.
I wouldn't worry about bugs yet. I suggest we mark the Python 3 branch as experimental once we have agreed on where and how we set it up.
I find it hard to understand most of my old code in Jack, too. That's simply because it is a terrible mess. We should feel free to restructure and improve it, with no fear of breaking things.
When comparing my now obsolete Python 3 tree to the others, I see no fundamental differences in how @madarche, @gaetano-guerriero and @pimzand handled things. We all should get along fine.
Re-Tagging my music collection is how I plan to test jack4, too! :) Additionally, I have a few CDs that I need to rip.
I suggest we set up a Python 3 branch here and put @pimzand's tree into it, with or without my pull request which I can always add later. Then we set up github issues for known issues and for discussing the way ahead. I'm open to using other ways of communicating. There seem to be many ways of organizing a team in github, but I have no experience with those tools. I can learn, if needed.
I'm aware that everybody involved probably has limited time to work on Jack, me included. I'd just like us to agree on the basics. Then everyone can work on whatever they feel motivated to und have time for.
And thanks to @simon-budig for bringing us together. Highly appreciated!
Sadly I have never managed to save enough time to work on jack after the setting of the organization and repository with @gaetano-guerrieroš¢ And I don't think this situation can improve in the near futureā¦
But I'm always working on GitHub and GitLab. So I'll always be around to help on the org and repo if needed, and also to give additional access to future contributors if some of you leave the project for any reason.
So do as you feel without me, and just @madarche me if you need!
Since pimzand/jack started as a fork of jack-cli-cd-ripper/jack, I could turn all my work into a giant pull request. Would you consider that a good idea? I suppose we should create a branch first.
Is there some common ancestry in jack-cli-cd-ripper/jack and zzarne/jack ?
Is there some common ancestry in jack-cli-cd-ripper/jack and zzarne/jack ?
There is no common ancestry in terms of shared Git commits (i.e. wrt id SHA1), for example https://github.com/jack-cli-cd-ripper/jack/commit/eb09f65671ccb550e3ad8d4a3a94fac63c5fd02b and https://github.com/zzarne/jack/commit/364260c10442416874fa0d384e73664f651bb027 which have the same content but different id SHA1.
But in terms of content, nothing is missing from either repository.
I've created a branch python3-mb for the Python 3 port + MusicBrainz.
@pimzand you can use that, merge or rebase in your changes and create a pull request. I can then apply my changes on top.
How hard would it be to port this application to python 3? I am still using this on Fedora, and Fedora 32, released today has deprecated python 2.