This has been been discussed, but rejected for various reasons. The alternative to SF would have been gitlab rather than github, though.
As for commits-as-patches I assume you can get around it by cloning the repo and then use git cherry-pick or git format-patch depending on your use case?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Given the not very active state of the project, and the lack of planned future developments, the smartest thing may be to just keep it as it is. Think of how many links on the Internet that will break. For example lirc.org...
But in the end, I think that the ones who are active (Sean?) should decide.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a few more bugs I want to fix, and I'd like to do a 0.10.3 release. I hope that will be some time this year. I'll continue to do merge bug fixes but it will be sporadic, just it has been in the past. Not really fast paced so it's fine where it is.
On the other, hand gitlab is pretty nice and allows us to things like CI. You can set the project to be moved on sourceforge, so the existing URLs to lirc will just redirect to the new gitlab.
We would also need to move lirc-remotes and other repos, and migrate all the issues/MRs. I haven't found a great way of that doing that from SF to gitlab other than doing a json export and then writing some scripts myself.
But it is really worth all the effort for a project that is seeing very little activity.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been been discussed, but rejected for various reasons. The alternative to SF would have been gitlab rather than github, though.
As for commits-as-patches I assume you can get around it by cloning the repo and then use git cherry-pick or git format-patch depending on your use case?
I'm pulling in my buil procedures patches over http.
SF does not provide such way to obrtain patch when hash commit is known.
I would recommend github because in gitlab emial notyfications (like new version) does not work at all and gitlab refuses to fix that from more than three years.
Other thing is that github off3r signing commits and tagged trees https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your
Can you provide a link?
gentle ping :)
I am all for moving lirc to gitlab. We can get hosting on https://gitlab.freedesktop.org/
Any objections to moving the repo?
I propose to the team to move on GitHub, it is possible?
Thanks in advance.
I think we're in agreement that gitlab would be preferable to github. gitlab is open source infrastructure and github is not.
Given the not very active state of the project, and the lack of planned future developments, the smartest thing may be to just keep it as it is. Think of how many links on the Internet that will break. For example lirc.org...
But in the end, I think that the ones who are active (Sean?) should decide.
@seanyoung: Thanks for your answer.
For me, there are more developers on GitHub.
You can create a mirror to link GitHub and Gitlab :)
TBH, I am in two minds about this.
There are a few more bugs I want to fix, and I'd like to do a 0.10.3 release. I hope that will be some time this year. I'll continue to do merge bug fixes but it will be sporadic, just it has been in the past. Not really fast paced so it's fine where it is.
On the other, hand gitlab is pretty nice and allows us to things like CI. You can set the project to be moved on sourceforge, so the existing URLs to lirc will just redirect to the new gitlab.
We would also need to move lirc-remotes and other repos, and migrate all the issues/MRs. I haven't found a great way of that doing that from SF to gitlab other than doing a json export and then writing some scripts myself.
But it is really worth all the effort for a project that is seeing very little activity.