I agree it is a good idea to use Git (or Mercurial) instead of CVS.
I already proposed this a few years ago, and I even have some scripts for creating a Git mirror of a CVS repository. I did not do it until now because it is some work which needs time. In addition to the repository conversion the script ReleaseBuild.sh and the corresponding instructions in ReleaseBuild must be adapted to Git.
What is the advantage of moving to Github instead of using a Git repository on Sourceforge?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the advantage of moving to Github instead of using a Git repository on Sourceforge?
I didn't know until now that SF supports git. When I moved my projects to git it didn't and so did I move to github. Additionally I have the impression (which I can't prove) that the user base is bigger on Github. I cannot tell anything about the user experience here but github's is great. Everything is build around git. You don't even have to use the web interface for releasing. I remember this terrible process of creating releases here. This probably changed.
Well I guess git on SF is OK though, but moving from CVS would still be a nice feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Git repository is not ready yet.
I'm in the process of changing the script ReleaseBuild.sh to work with Git instead of CVS. I will also try to automate some more steps of putting all the stuff to the files section.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as stated in [#694], I would make the transfer to GitHub for you in the coming months if you allow it. At the end of the process I would transfer ownership of the GitHub project to your account on GitHub.
Following reasons from my point of view speak for a transfer to GitHub instead of just switching to Git:
pull requests: make it easier to comment and test proposed patches (IIRC: I can directly "clone" a pull request from the command line)
release: can be fully automated with the help of GitHub API
I suppose people are more familiar with the GitHub web UI by now than with SourceForge and find it more convenient. So, a bigger pool of contributors might be reached.
I would try to not only move the repository, but any open ticket (after re-evaluation). From a quick glance I think, that I can adapt ReleaseBuild.sh as well.
This leaves the two active mailing lists (change and release), which GitHub cannot replicate. But there are alternatives:
I'm not convinced yet.
I don't want to change all the infrastructure just for moving from SF to GitHub. (I don't prefer SF in general, I also have other things hosted on GitHub.)
Pull requests as such are supported by Git. I think SF calls them "merge request". Maybe GitHub has the advantage of saving pull requests to your repository. (In case the author deletes his repository before I integrate the pull request.)
The release process also updates some files on the web space at esniper.sf.net although the main text has not been changed for a long time.
One important thing is the file version.txt on this web server which is checked when esniper generates an automatic bug report. The corresponding URL must be kept for compatibility with old versions. (New versions could use a new URL.)
The automated bug report mechanism displays a SF URL, so this should be kept as well, at least for some time.
If we really decide to have the Git repo on GitHub instead of SF, there ia also a feature to automatically get GitHub releases to SF, see https://sourceforge.net/p/esniper/admin/files/gh_integration. So we could still use SF for webspace, files download, mailing list and bug tracker.
I think the first step should be to adapt ReleaseBuild.sh to work with Git instead of CVS.
The Git repo here does not yet have the latest CVS commits, but it should be sufficient for testing. I may have to throw away and re-create the repo to import the latest CVS commits. So we have to re-integrate the changes after the final CVS->Git conversion. (The conversion is done manually with the help of a few scipts and will fail if the target Git repo contains commits other than those converted from CVS.)
The manual steps to upload files to the download area and project web site and managing the default download should also be added to ReleaseBuild.sh.
When moving from CVS to git we should also consider using the git-flow branching model. This may require some manual work to get the CVS import into develop instead of master.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I vote for the move to GitHub. It simplifies a lot of things, because the chances are high, that people are more fluent with GitHub than SF.
And, I woul keep things as simple as possible. Keep everything on SF up the version before moving to GitHub, and all newer stuff comes from GitHub. There is no need to link both. It's just adding non-value complexity.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please keep in mind, that only volunteers working on this project in their leisure time. Things like git, automated nightly builds etc. must be configured and tested.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Of course Git on SF is not the same as using Github.
If there is a consensus between active developers to move to Github I don't have a problem with this although I don't see a big advantage.
Some could argue that e.g. Gitlab should be preferred over Github.
On the other hand I would also agree to close this ticket as "wont-fix".
Some of the arguments are merely theoretical:
"chances are high, that people are more fluent with GitHub than SF" or
"I suppose people are more familiar with the GitHub web UI [...] So, a bigger pool of contributors might be reached."
I don't know the differences, but merge requests here are similar to pull requests at Github.
I get automatic notification e-mails when something gets pushed to the Git repo here. So this feature exists as well.
The release process is only partially automated, there are still 3 manual steps as documented in ReleaseBuild, simply because nobody has done it yet.
And more than once I was glad that the announce mailing process is manual and the moderated mailing list requires (allows) me to accept or reject my own mail.
As I already explained in a previous comment, there are some features that depend on SF infrastructure:
- ReleaseBuild documentation and corresponding script ReleaseBuild.sh
- check for latest version number before bug report
- instructions for automated bug reports printed by the program.
All this can be changed, but someone has to do the work.
Our main problem is the lack of developers or lack of time, and I don't believe that we will magically get more active developers when the main repository is moved to Github.
I would be convinced to do the move to Github (or Gitlab or whatever) if
- an active developer votes for moving or
- there is at least one new developer plausibly promising to participate after moving.
Bodo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How about doing a lite migration? That is, create an official fork a GH so that people can contribute there. Keep everything as it is so that you can use the existing infrastructure. That way you can see if participation changed and then decide to migrate completely or roll back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Markus Malkusch: What exactly prevents you from contributing? Would this change if the main repository was on Github? In case you are not able to contribute to esniper's code you could create a fork/mirror on Github and manage it. Then let's see how this will attract developers.
What is possible on GH without registration what you cannot do here on SF?
Maybe some setting should be changed here.
But: At some point in the past we changed the bug tracker to require registration because we got spam. This registration barrier reduced spam, maybe it also reduced the number of legitimate bug reports.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For me there's nothing which prevents contribution here, because I did had this old SF account. But there are people out there who cannot be bother to register here and there's an order of magnitute more people who are registered at GitHub.
I did create a mirror here: https://github.com/esniper-org/esniper
It only makes sense if you would reference that repository here, so that people know they can contribute there. However I'm not going to maintain that repository. If PRs would come in, somebody else would need to take ownership as unfortunately I can't commit myself for that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, but simply creating a mirror without maintaining it doesn't help. We need a volunteer to do the work, not theoretical advantages only.
Will the repository on GitHub automatically mirror the repo (or maybe the master branch) on SF or does this require manual work (or a script)?
I think it's not a good idea to add a second bug tracker. This should be disabled as long as SF is the primary site for development.
If you add a mirror for releases you should make sure they are not different from the original ones.
You can build the same binary from the release archives on GitHub, but naming, content and internal structure are different. See the script ReleaseBuild.sh or compare the archives.
Before using Github's release mechanism the repository contents should be cleaned up and split into main program and PHP frontend. (The last commit in the php subdirectorywas more than 10 years ago. I never used it, and I don't know if it would still work.)
Without someone to maintain the mirror it doesn't make sense to announce it.
("There is a mirror on GitHub, but we don't know if/when somebody cares about it.")
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, here's my actual take on this (my previous comments were simply directed at not closing this ticket for the wrong reason).
1) I believe sf.net has well run its course and most people have moved on decades (!) ago
2) nonetheless, the infrastructure works well enough, certainly for esniper contributors
3) the argument of widening the contributor base sounds good in theory, but falls apart in daylight: if somebody cannot be bothered to register an account here then it is highly improbable that person is motivated enough to make even half-way serious contributions. Anybody who feels excluded because of where esniper is hosted is certainly more than welcome to make the move as part of their contribution and it sounds to me as if the devs would most likely follow willingly. None of us feel strongly enough to MAKE it happen on our time, though.
Making requests of of others and shying away from doing at least some of the work necessary isn't how FOSS can work in a sustainable way. From where I stand, it looks like all the people investing at least some time in maintaining esniper are not going to step up to do the work needed for the move. As such, the mantra of "patches welcome" applies or in this case "taking ownership of the process to make the move happen welcome" but until then it won't happen for now.
Suggesting to close as wontfix (until someone steps up to drive the move)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree it is a good idea to use Git (or Mercurial) instead of CVS.
I already proposed this a few years ago, and I even have some scripts for creating a Git mirror of a CVS repository. I did not do it until now because it is some work which needs time. In addition to the repository conversion the script ReleaseBuild.sh and the corresponding instructions in ReleaseBuild must be adapted to Git.
What is the advantage of moving to Github instead of using a Git repository on Sourceforge?
I didn't know until now that SF supports git. When I moved my projects to git it didn't and so did I move to github. Additionally I have the impression (which I can't prove) that the user base is bigger on Github. I cannot tell anything about the user experience here but github's is great. Everything is build around git. You don't even have to use the web interface for releasing. I remember this terrible process of creating releases here. This probably changed.
Well I guess git on SF is OK though, but moving from CVS would still be a nice feature.
Yeah, I discovered git://git.code.sf.net/p/esniper/code-git. Great!
The Git repository is not ready yet.
I'm in the process of changing the script ReleaseBuild.sh to work with Git instead of CVS. I will also try to automate some more steps of putting all the stuff to the files section.
http://helb.github.io/goodbye-sourceforge/
Hey Bodo,
as stated in [#694], I would make the transfer to GitHub for you in the coming months if you allow it. At the end of the process I would transfer ownership of the GitHub project to your account on GitHub.
Following reasons from my point of view speak for a transfer to GitHub instead of just switching to Git:
I would try to not only move the repository, but any open ticket (after re-evaluation). From a quick glance I think, that I can adapt ReleaseBuild.sh as well.
This leaves the two active mailing lists (change and release), which GitHub cannot replicate. But there are alternatives:
The big difference to mailing lists being that you need an login to GitHub for both …
Did I forget something? What do you think?
Related
Bugs:
#694I'm not convinced yet.
I don't want to change all the infrastructure just for moving from SF to GitHub. (I don't prefer SF in general, I also have other things hosted on GitHub.)
Pull requests as such are supported by Git. I think SF calls them "merge request". Maybe GitHub has the advantage of saving pull requests to your repository. (In case the author deletes his repository before I integrate the pull request.)
I agree that releases may be a bit easier with GitHub API, but there are only a few steps missing from ReleaseBuild.sh. See the ReleaseBuild text file and https://sourceforge.net/p/forge/community-docs/Using%20the%20Release%20API/
The release process also updates some files on the web space at esniper.sf.net although the main text has not been changed for a long time.
One important thing is the file version.txt on this web server which is checked when esniper generates an automatic bug report. The corresponding URL must be kept for compatibility with old versions. (New versions could use a new URL.)
The automated bug report mechanism displays a SF URL, so this should be kept as well, at least for some time.
If we really decide to have the Git repo on GitHub instead of SF, there ia also a feature to automatically get GitHub releases to SF, see https://sourceforge.net/p/esniper/admin/files/gh_integration. So we could still use SF for webspace, files download, mailing list and bug tracker.
I think the first step should be to adapt ReleaseBuild.sh to work with Git instead of CVS.
The Git repo here does not yet have the latest CVS commits, but it should be sufficient for testing. I may have to throw away and re-create the repo to import the latest CVS commits. So we have to re-integrate the changes after the final CVS->Git conversion. (The conversion is done manually with the help of a few scipts and will fail if the target Git repo contains commits other than those converted from CVS.)
The manual steps to upload files to the download area and project web site and managing the default download should also be added to ReleaseBuild.sh.
When moving from CVS to git we should also consider using the git-flow branching model. This may require some manual work to get the CVS import into develop instead of master.
I vote for the move to GitHub. It simplifies a lot of things, because the chances are high, that people are more fluent with GitHub than SF.
And, I woul keep things as simple as possible. Keep everything on SF up the version before moving to GitHub, and all newer stuff comes from GitHub. There is no need to link both. It's just adding non-value complexity.
+1
+1
Please keep in mind, that only volunteers working on this project in their leisure time. Things like git, automated nightly builds etc. must be configured and tested.
How is this closed? we're still on SF, right?
We are still at SF, but using the git repository instead of cvs.
People argued that's not quite the same, though.
Ok, reopened. But who will manage two repositories ?
Of course Git on SF is not the same as using Github.
If there is a consensus between active developers to move to Github I don't have a problem with this although I don't see a big advantage.
Some could argue that e.g. Gitlab should be preferred over Github.
On the other hand I would also agree to close this ticket as "wont-fix".
Some of the arguments are merely theoretical:
"chances are high, that people are more fluent with GitHub than SF" or
"I suppose people are more familiar with the GitHub web UI [...] So, a bigger pool of contributors might be reached."
I don't know the differences, but merge requests here are similar to pull requests at Github.
I get automatic notification e-mails when something gets pushed to the Git repo here. So this feature exists as well.
The release process is only partially automated, there are still 3 manual steps as documented in ReleaseBuild, simply because nobody has done it yet.
And more than once I was glad that the announce mailing process is manual and the moderated mailing list requires (allows) me to accept or reject my own mail.
As I already explained in a previous comment, there are some features that depend on SF infrastructure:
- ReleaseBuild documentation and corresponding script ReleaseBuild.sh
- check for latest version number before bug report
- instructions for automated bug reports printed by the program.
All this can be changed, but someone has to do the work.
Our main problem is the lack of developers or lack of time, and I don't believe that we will magically get more active developers when the main repository is moved to Github.
I would be convinced to do the move to Github (or Gitlab or whatever) if
- an active developer votes for moving or
- there is at least one new developer plausibly promising to participate after moving.
Bodo
Github has a much greater user base:
https://www.alexa.com/siteinfo/github.com
vs
https://www.alexa.com/siteinfo/sourceforge.net
Registration is a contribution barrier.
How about doing a lite migration? That is, create an official fork a GH so that people can contribute there. Keep everything as it is so that you can use the existing infrastructure. That way you can see if participation changed and then decide to migrate completely or roll back.
@Markus Malkusch: What exactly prevents you from contributing? Would this change if the main repository was on Github? In case you are not able to contribute to esniper's code you could create a fork/mirror on Github and manage it. Then let's see how this will attract developers.
What is possible on GH without registration what you cannot do here on SF?
Maybe some setting should be changed here.
But: At some point in the past we changed the bug tracker to require registration because we got spam. This registration barrier reduced spam, maybe it also reduced the number of legitimate bug reports.
For me there's nothing which prevents contribution here, because I did had this old SF account. But there are people out there who cannot be bother to register here and there's an order of magnitute more people who are registered at GitHub.
I did create a mirror here: https://github.com/esniper-org/esniper
It only makes sense if you would reference that repository here, so that people know they can contribute there. However I'm not going to maintain that repository. If PRs would come in, somebody else would need to take ownership as unfortunately I can't commit myself for that.
I'm sorry, but simply creating a mirror without maintaining it doesn't help. We need a volunteer to do the work, not theoretical advantages only.
Will the repository on GitHub automatically mirror the repo (or maybe the master branch) on SF or does this require manual work (or a script)?
I think it's not a good idea to add a second bug tracker. This should be disabled as long as SF is the primary site for development.
If you add a mirror for releases you should make sure they are not different from the original ones.
You can build the same binary from the release archives on GitHub, but naming, content and internal structure are different. See the script ReleaseBuild.sh or compare the archives.
Before using Github's release mechanism the repository contents should be cleaned up and split into main program and PHP frontend. (The last commit in the php subdirectorywas more than 10 years ago. I never used it, and I don't know if it would still work.)
Without someone to maintain the mirror it doesn't make sense to announce it.
("There is a mirror on GitHub, but we don't know if/when somebody cares about it.")
Ok, I remove it then. Sorry for the friction. I think https://sourceforge.net/u/krikkel/ was willing to put more time into the migration.
OK, here's my actual take on this (my previous comments were simply directed at not closing this ticket for the wrong reason).
1) I believe sf.net has well run its course and most people have moved on decades (!) ago
2) nonetheless, the infrastructure works well enough, certainly for esniper contributors
3) the argument of widening the contributor base sounds good in theory, but falls apart in daylight: if somebody cannot be bothered to register an account here then it is highly improbable that person is motivated enough to make even half-way serious contributions. Anybody who feels excluded because of where esniper is hosted is certainly more than welcome to make the move as part of their contribution and it sounds to me as if the devs would most likely follow willingly. None of us feel strongly enough to MAKE it happen on our time, though.
Making requests of of others and shying away from doing at least some of the work necessary isn't how FOSS can work in a sustainable way. From where I stand, it looks like all the people investing at least some time in maintaining esniper are not going to step up to do the work needed for the move. As such, the mantra of "patches welcome" applies or in this case "taking ownership of the process to make the move happen welcome" but until then it won't happen for now.
Suggesting to close as wontfix (until someone steps up to drive the move)