GitHub migration procedure
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
Further steps I did:
Moved and renamed freeorion-fixed to freeorion-archive:freeorion-backup3.
Moved and renamed freeorion-backup3 to freeorion-archive:freeorion-backup4.
Moved and renamed freeorion-fixed to freeorion-archive:freeorion-backup3.
Moved and renamed freeorion-backup3 to freeorion-archive:freeorion-backup4.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
Is there a good "just tell me how to get the source so I can build it" method for the GitHub repository? Something so that people don't need to know anything about how git works? Just the Download ZIP button at the bottom right of the repository page perhaps?
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
For people, who don't want to contribute, but just get the code?Geoff the Medio wrote:Is there a good "just tell me how to get the source so I can build it" method for the GitHub repository? Something so that people don't need to know anything about how git works? Just the Download ZIP button at the bottom right of the repository page perhaps?
https://github.com/freeorion/freeorion/releases -> For a listing of all tags
https://github.com/freeorion/freeorion/archive/<BRANCH OR TAG NAME HERE>.zip for a zip file.
https://github.com/freeorion/freeorion/archive/<BRANCH OR TAG NAME HERE>.tar.gz for a gzipped tarball.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: GitHub migration procedure
For a snapshot of the most recent commit of the selected branch, yes. If someone wants the sourcecode of, e.g., the 0.4.4 release, the approach Marcel pointed out would be the way to go.Geoff the Medio wrote:Just the Download ZIP button at the bottom right of the repository page perhaps?
Re: GitHub migration procedure
So, just edited and updated the OP once more to reflect the latest progress. As the migration of the repo is now complete, it's now time to take care of the cleanup steps.
Marcel already mentioned a few things:
As for porting open tickets to github, if we really want to do that, I don't think there's any other way than manually recreating them... ugh. Which raises the question: Do we want to do that?
Now to the things still left from the list in the OP of this thread:
* Adjusting build number composition (that includes file name scheme of binary releases, both test and stable) and the Python script that produces version.cpp and the version string. I've already posted a proposal, I'll probably make that into a pull request (have to learn how to do that anyway).
* Update the SDKs. I'll do the OSX SDK of course, Geoff, if you want me to, I can also take a look at the Windows SDK.
* Decide on what needs to be changed/updated about the FreeOrion project on SF:
** What to do with the repo? Should it stay as a read-only backup, should we remove it entirely? I definitely prefer keeping it as a read-only backup (meaning, leaving it as it is now - commit access has already been revoked from everyone except project admins).
** What should be changed on the front page to indicate the official repo is now on github? What are our options anyway? At least the text needs to change to state that the SF repo is now only a legacy repo kept for backup purposes, and provide a link to the official repo on github.
* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
Pls add you 2 cents
Marcel already mentioned a few things:
Just to be sure before I proceed with that step: Anyone any objections? If yes, let him now speak or forever hold his peace.adrian_broher wrote:* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
I suggest to wait a bit, in case we change our mind and decide we want to merge the branch into master after all.* Delete the release-v0.4.4 branch. The release has already a tag, which keeps the history alive and we don't work on a bugfix release for v0.4.4 so no branch is required here IMO.
Long overdue, done.* Delete the v0.4.4-rc* tags. Tags do mainly map to releases on github. I don't think that end users are really interested into our internal testing release candidates.
Dilvish and I already expressed a preference for closing down the trackers on SF and use the github issues tracker in future. Still waiting for Geoff to make the final call. Then we need to figure out how to do that: I know how to remove these trackers from the freeorion project on SF (which will delete their entire contents), but it might be more sensible to keep them and just make them read-only. Not sure if that's possible, and if it is, how to do that.If or how we migrate the open tickets and feature requests from sourceforge to github.
As for porting open tickets to github, if we really want to do that, I don't think there's any other way than manually recreating them... ugh. Which raises the question: Do we want to do that?
Now to the things still left from the list in the OP of this thread:
* Adjusting build number composition (that includes file name scheme of binary releases, both test and stable) and the Python script that produces version.cpp and the version string. I've already posted a proposal, I'll probably make that into a pull request (have to learn how to do that anyway).
* Update the SDKs. I'll do the OSX SDK of course, Geoff, if you want me to, I can also take a look at the Windows SDK.
* Decide on what needs to be changed/updated about the FreeOrion project on SF:
** What to do with the repo? Should it stay as a read-only backup, should we remove it entirely? I definitely prefer keeping it as a read-only backup (meaning, leaving it as it is now - commit access has already been revoked from everyone except project admins).
** What should be changed on the front page to indicate the official repo is now on github? What are our options anyway? At least the text needs to change to state that the SF repo is now only a legacy repo kept for backup purposes, and provide a link to the official repo on github.
* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
Pls add you 2 cents
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
There seems to be a mechanism on github for publishing binaries... Go to a tag page, click Edit Tag, and there are options to attach images or "Attach binaries by dropping them here or selecting them."Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
Re: GitHub migration procedure
I've moved the further discussion on that issue to the The Git/GitHub Questions, Answers and Howto Thread. Please continue the discussion there.adrian_broher wrote:I don't understand your question, sorry.Geoff the Medio wrote:What does having a tag mean if the branch containing the commit that was tagged is deleted...?
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
There may be issues with using GitHub for binary distribution, though... At least at some point they appear to have disabled the feature and suggested using SourceForge instead. SF also does have some possibly-interesting analytics, such as a total downloads counter.Geoff the Medio wrote:There seems to be a mechanism on github for publishing binaries... Go to a tag page, click Edit Tag, and there are options to attach images or "Attach binaries by dropping them here or selecting them."Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
Re: GitHub migration procedure
Moved the reply to this post to the The Git/GitHub Questions, Answers and Howto Thread. Please continue the discussion there.MatGB wrote:And now all you have to do is explain what us poor plebs have to do
(from what's been said, I'll not bother with TortoiseGit and instead try one of the other options, this might be fun...)
Re: GitHub migration procedure
For stable releases this might work, but obviously not for our weekly test builds.Geoff the Medio wrote:There seems to be a mechanism on github for publishing binaries... Go to a tag page, click Edit Tag, and there are options to attach images or "Attach binaries by dropping them here or selecting them."
So, I guess another point has been decided. Binary releases will be provided on SF.Geoff the Medio wrote:There may be issues with using GitHub for binary distribution, though... At least at some point they appear to have disabled the feature and suggested using SourceForge instead. SF also does have some possibly-interesting analytics, such as a total downloads counter.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
No, I thought of testing this software: https://github.com/ttencate/sf2github and if the results are good we should use that and migrate the whole issue history.Vezzra wrote:Dilvish and I already expressed a preference for closing down the trackers on SF and use the github issues tracker in future. Still waiting for Geoff to make the final call. Then we need to figure out how to do that: I know how to remove these trackers from the freeorion project on SF (which will delete their entire contents), but it might be more sensible to keep them and just make them read-only. Not sure if that's possible, and if it is, how to do that.
As for porting open tickets to github, if we really want to do that, I don't think there's any other way than manually recreating them... ugh. Which raises the question: Do we want to do that?
I would not keep it as a backup, just as a defunct repository.Vezzra wrote:** What to do with the repo? Should it stay as a read-only backup, should we remove it entirely? I definitely prefer keeping it as a read-only backup (meaning, leaving it as it is now - commit access has already been revoked from everyone except project admins).
See how the TigerVNC did it for example: http://sourceforge.net/projects/tigervnc/Vezzra wrote:** What should be changed on the front page to indicate the official repo is now on github? What are our options anyway? At least the text needs to change to state that the SF repo is now only a legacy repo kept for backup purposes, and provide a link to the official repo on github.
Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
That was some time ago. GitHub still supports binary releases. https://help.github.com/articles/distri ... -binaries/Geoff the Medio wrote:There may be issues with using GitHub for binary distribution, though... At least at some point they appear to have disabled the feature and suggested using SourceForge instead. SF also does have some possibly-interesting analytics, such as a total downloads counter.
Quote from stackoverflow:
But when looking at the TigerVNC page I found out about https://bintray.com/, a "platform for automated software distribution". TigerVNC uses it to provide their windows installers, mac bundles, (selected) linux packages and also a tarball. Maybe this platform is also worth investigating.http://stackoverflow.com/revisions/13892441/3 wrote: On Dec 11, 2012 "Upload Releases" functionality aka "Downloads" was deprecated.
https://github.com/blog/1302-goodbye-uploads
Update: On July 2, 2013 GitHub team announced a new "Releases" feature as a replacement for "Downloads"
https://github.com/blog/1547-release-your-software
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: GitHub migration procedure
Geoff, in order to test the issue migration I need an export of the tracker data, could you please send me that export file?
https://github.com/ttencate/sf2github#usage
https://github.com/ttencate/sf2github#usage
From SourceForge, you need to export the tracker data. This is done through
the Export function of the admin interface.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13603
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: GitHub migration procedure
Attached, hopefully.adrian_broher wrote:Geoff, in order to test the issue migration I need an export of the tracker data, could you please send me that export file?
- Attachments
-
- freeorion-backup-2015-03-30-093844.zip
- bugs and feature requests data export
- (491.17 KiB) Downloaded 212 times
Re: GitHub migration procedure
Done.Vezzra wrote:Just to be sure before I proceed with that step: Anyone any objections? If yes, let him now speak or forever hold his peace.adrian_broher wrote:* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
Re: GitHub migration procedure
Updated OP.