Name change in case of fork, packaging
eeickmeyer opened this issue · 28 comments
Hi there! Not so much an issue as I wanted to thank you for taking-on this project since the DisplayCAL author isn't willing or motivated. He hasn't even addressed Debian and Ubuntu dropping the Python2-based dependencies, or that various distributions have dropped DisplayCAL due to the lack of those dependencies. He seems to be only concerned with Windows and Arch, which means everyone else suffers.
Anyhow, I'm the leader of Ubuntu Studio, and as a photographer (among other things), it has been immensely frustrating for me to not have DisplayCAL available to myself and my users. So, I'm glad to see this happening.
The only issue that I can see is that you are keeping the name DisplayCAL. You might consider a different name for a proper fork (if necessary or if he doesn't accept your contribution, as he seems to not be interested in anyone else contributing) since, per that GPL at least, forks aren't allowed to carry the same name unless the original author has completely handed over the original project.
I'm a MOTU with Ubuntu, so I'd be happy to handle packaging and upload it. I can see it definitely landing in Ubuntu 21.10, but 21.04 closes for new packages late this month for beta freeze.
Thanks. Maybe I'll start getting this on the road again - since there's a possibility, what do you think in terms of names?
Cald
Calp
displayprof maybe, as in display profiler.
ProfDisplay
DisProf
CaliDis, ColorDis
DisplayAdjuster
I echo the thanks given above for taking this initiative. I'm only just getting exposed to Python now and on the learning topic of python2 to python3 conversion my thoughts went to DisplayCAL. Was saddened to see that things still appear to be unchanged since December 2019 but further searching led me here. Just wondering what the state of this project is - is it functional yet or still a work-in-progress? Just wondering if it's worth the time to try building this.
As for status, I would like to work on this but I've also just moved across the country. I've got a lot going on right now, but I also have displays to calibrate, so it's a tough one. Since putting this on github, I actually have not checked to see if anyone else has done work on porting - I would not be surprised either way.
Thanks for the update - I haven't seen any other (public) attempts to migrate to Python 3, hence my query. No worries about the busyness, I suppose it's no different from the busyness/reticence of the original author as well.
I'm an experienced Python Developer and a Photographer (also a VFX Supervisor, Pipeline Developer, Houdini FX Artist etc.). I'm using DisplayCAL for years and I'm willing to contribute. If you have any particular section of the code that you want me to focus in, I can look in to those.
Okay, with 2 days worth of work, I'm now able to build and install DispalyCAL with Python3.9. The RealDisplaySizeMM C-Extension module is also compiling with a couple of warnings. Running displaycal from the installed location is not working, complaining about the meta module is not found, which is normal, because it is not correctly imported, I'll fix that in the next commits... etc.
That sounds encouraging! If you do get something working - even partially - wondering if you should make a PR here or just make your own fork.
Amazing work @eoyilmaz !
I shall share this news with my friends
Okay, it is alive :)
Still needs a ton of work.
I can do a PR. But, if everything goes as planned, I would love to be the new maintainer for the code.
History is made!
Fantastic!
I can do a PR. But, if everything goes as planned, I would love to be the new maintainer for the code.
In lieu of any response from Roman I suppose you can just start your own fork. I suppose the issue regarding the name (that was brought up in the original issue report) still stands. I'm not an expert on licence issues, but DisplayCAL cites GPLv3 so I don't think there's any issue with you starting your own project based on the original work.
So, I'm returning back to my own repository and people are welcome there. I would probably need help with packaging things later on.
He seems to be only concerned with Windows and Arch, which means everyone else suffers.
Then I’m willing to drop it from Arch if it can help in anyway. I’m already using the flatpak version myself since I’ve got rid of py2 on my system.
But anyway, thanks to the awesome work of @eoyilmaz we might get a better solution! I’ll be glad to package a py3 version when it’s available (I won’t be able to test it soon though, because my ColorHug2 is ten thousands kilometres away from me). ;)
I'm opening an issue (eoyilmaz#1) related for the development in my repository. Please follow that issue to get status updates. I have some surprises 😄
Hey @RomanHargrave can you please update your README with the information pointing to: https://github.com/Doomsdayrs/displaycal-py3 https://github.com/eoyilmaz/displaycal-py3
I've a working version now ( almost 😄 ).
What? Why is it pointing to my repository??
Oops sorry, I was checking who forked it, I probably have copied the address from the wrong browser tab, sorry.
@eoyilmaz Per the GPLv3, with your fork you'll still have to come up with a new name as the original author still retains rights to the name DisplayCAL.
@eoyilmaz Yeah, I can note that. For what it's worth, I've ultimately ended up just using the argyll command line directly, even with how obtuse it can be. Maybe I'll drop in and help if I feel like using the UI again and you have some open issues.
Guys, I'm happy to let you know that the DisplayCAL is now working (https://github.com/eoyilmaz/displaycal-py3).
Please test it and please create issues for every single hiccup you encountered. There are very little automated tests, and I need the code to be tested constantly until we write enough tests that covers 100% of the code (which may not be possible).
Hey @RomanHargrave can you delete this repo and select my repository as the new parent repository.
I'm asking that, because, my repository is quite active now, and people are helping me with the development, I had one developer working on the project, who first worked on a fork of this one, then realized my repository, and had to do some rework.
For the sake of DisplayCAL's future, I think it is better to have my repository as the main repository.
What do you think?
@RomanHargrave any updates on my request?
@eoyilmaz You can also ask GitHub to remove the fork relation of your repo if you don’t get answers here.
(Using this form https://support.github.com/contact?tags=rr-forks. Only downside: other forks will still be forks of this repository, not yours.)
Let's wait for a while until we are sure that we don't have an answer.
Hey @RomanHargrave can you delete this repo and select my repository as the new parent repository.
I'm asking that, because, my repository is quite active now, and people are helping me with the development, I had one developer working on the project, who first worked on a fork of this one, then realized my repository, and had to do some rework.
I think the usual route is to mark the repo as archived, it would lock this issue thread and any further interactions on the repo.
The README was updated back in late feb if you didn't notice though, it clearly points users to your repo instead:
You can find a more developed copy of this code at https://github.com/eoyilmaz/displaycal-py3
It would be a bit more clearer upon archiving the project. The README was sufficient imo, along with this open issue (which will remain readable if archived).
Archiving will not do what I wanted to have. I want all the other forks to point to my repository, so that any useful change will find its way back to my repository, instead of this stale one.