GitHub migration procedure

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#181 Post by adrian_broher » Sun Mar 29, 2015 12:05 pm

Further steps I did:
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

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12249
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#182 Post by Geoff the Medio » Sun Mar 29, 2015 12:36 pm

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?

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#183 Post by adrian_broher » Sun Mar 29, 2015 12:40 pm

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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#184 Post by Vezzra » Sun Mar 29, 2015 12:51 pm

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.

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#185 Post by Vezzra » Sun Mar 29, 2015 2:06 pm

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

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12249
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#186 Post by Geoff the Medio » Sun Mar 29, 2015 2:13 pm

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."

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#187 Post by Vezzra » Sun Mar 29, 2015 2:23 pm

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.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12249
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#188 Post by Geoff the Medio » Sun Mar 29, 2015 2:27 pm

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.

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#189 Post by Vezzra » Sun Mar 29, 2015 2:30 pm

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.

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#190 Post by Vezzra » Sun Mar 29, 2015 2:38 pm

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.

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#191 Post by adrian_broher » Sun Mar 29, 2015 3:02 pm

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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
adrian_broher
Programmer
Posts: 1072
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: GitHub migration procedure

#192 Post by adrian_broher » Mon Mar 30, 2015 9:13 am

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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 12249
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#193 Post by Geoff the Medio » Mon Mar 30, 2015 10:02 am

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.
Attachments
freeorion-backup-2015-03-30-093844.zip
bugs and feature requests data export
(491.17 KiB) Downloaded 66 times

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#194 Post by Vezzra » Tue Mar 31, 2015 5:22 pm

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.

User avatar
Vezzra
Release Manager, Design
Posts: 4610
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#195 Post by Vezzra » Tue Mar 31, 2015 6:04 pm

Updated OP.

Post Reply