Page 13 of 14

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 12:05 pm
by adrian_broher
Further steps I did:
Moved and renamed freeorion-fixed to freeorion-archive:freeorion-backup3.
Moved and renamed freeorion-backup3 to freeorion-archive:freeorion-backup4.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 12:36 pm
by Geoff the Medio
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?

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 12:40 pm
by adrian_broher
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?
For people, who don't want to contribute, but just get the code?

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.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 12:51 pm
by Vezzra
Geoff the Medio wrote:Just the Download ZIP button at the bottom right of the repository page perhaps?
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.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:06 pm
by Vezzra
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:
adrian_broher wrote:* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
Just to be sure before I proceed with that step: Anyone any objections? If yes, let him now speak or forever hold his peace. :mrgreen:
* 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.
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 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.
Long overdue, done.
If or how we migrate the open tickets and feature requests from sourceforge to github.
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?

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 :D

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:13 pm
by Geoff the Medio
Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
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."

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:23 pm
by Vezzra
adrian_broher wrote:
Geoff the Medio wrote:What does having a tag mean if the branch containing the commit that was tagged is deleted...?
I don't understand your question, sorry.
I've moved the further discussion on that issue to the The Git/GitHub Questions, Answers and Howto Thread. Please continue the discussion there.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:27 pm
by Geoff the Medio
Geoff the Medio wrote:
Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
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."
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.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:30 pm
by Vezzra
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...)
Moved the reply to this post to the The Git/GitHub Questions, Answers and Howto Thread. Please continue the discussion there.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 2:38 pm
by Vezzra
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."
For stable releases this might work, but obviously not for our weekly test builds.
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.
So, I guess another point has been decided. Binary releases will be provided on SF.

Re: GitHub migration procedure

Posted: Sun Mar 29, 2015 3:02 pm
by adrian_broher
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?
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:** 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).
I would not keep it as a backup, just as a defunct repository.
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.
See how the TigerVNC did it for example: http://sourceforge.net/projects/tigervnc/
Vezzra wrote:* Continue publishing binary releases on SF, or is there a similar feature on github, and if, shall we use that instead?
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.
That was some time ago. GitHub still supports binary releases. https://help.github.com/articles/distri ... -binaries/

Quote from stackoverflow:
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
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.

Re: GitHub migration procedure

Posted: Mon Mar 30, 2015 9:13 am
by adrian_broher
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
From SourceForge, you need to export the tracker data. This is done through
the Export function of the admin interface.

Re: GitHub migration procedure

Posted: Mon Mar 30, 2015 10:02 am
by Geoff the Medio
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?
Attached, hopefully.

Re: GitHub migration procedure

Posted: Tue Mar 31, 2015 5:22 pm
by Vezzra
Vezzra wrote:
adrian_broher wrote:* Delete all merged branches to remove clutter. So every branch except: master, release-v0.4.4 and logging-migration.
Just to be sure before I proceed with that step: Anyone any objections? If yes, let him now speak or forever hold his peace. :mrgreen:
Done.

Re: GitHub migration procedure

Posted: Tue Mar 31, 2015 6:04 pm
by Vezzra
Updated OP.