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
Vezzra
Release Manager, Design
Posts: 4999
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: GitHub migration procedure

#151 Post by Vezzra » Sat Mar 28, 2015 7:21 pm

adrian_broher wrote:Anyway, how should we progress now? The only thing that prevents me uploading the new repo is the question about merging release-v0.4.4 or not.
That depends on what "stitching back into master" means - is this just a link you set, so that git describe works, or will actual merging (as in actual changes in master wil happen because of this) be done? If the latter is the case, I'd vote for not to merge, upload the new repo, and we can figure out if we want to merge afterwards, assuming that can be done with a normal git merge. Gives us more time to check more carefully what we actually might want to merge into master from the release branch.

If that just connects the release branch back to master with regard to the commit history graph, I won't object (although I still prefer not to merge, but as I said before, not strong opinion on that).

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

Re: GitHub migration procedure

#152 Post by Vezzra » Sat Mar 28, 2015 7:25 pm

adrian_broher wrote:If you're talking about "Temporary git-compatible version string generation." Yes, I added that. The major problem with it was the missmatch of line endings (and that one invalid file added). I can remove the commit (actually the offending part in the cmake file) easily if you incline so.
As Geoff made that commit, that's his decision. Judging by the answer he just posted, it should stay.

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

Re: GitHub migration procedure

#153 Post by adrian_broher » Sat Mar 28, 2015 7:31 pm

Geoff the Medio wrote:For release branches, isn't the point of them to separate stuff away from the master branch that shouldn't be in master as it is release-specific? Anything that should be merged from release back to master should just be done in master and merged the other way. That said, the use of a branch for the v0.4.4 release was a new procedure, so if that's not how release-specific changes would normally be dealt with on git, then there's no need to do so in future. (A release branch isn't a temporary space to work on a feature... it's a permanent divergence from the master development line.) For the v0.4.4 branch, presumably any important commits can be cherry-picked back to master, as effectively was done for the changelog. Then presumably it should just be left as is.
For me personally the release branch concept served the purpose of 'slowing down' release development without blocking main branch development. You maybe remember that this was the exact reason why I asked for a release branch in the first place [1][2]. It's to disconnect main development from release development. This allows risky, application breaking changes on the main development branch while the people, who do the release can do sensible cherry picking for bug fix changes.
Geoff the Medio wrote:Anything else I've committed to freeorion/freeorion is intended to be permanent, before and after re-re-recreation of the repository. To that end, can one cherry-pick from a different repository? I'd like to easily get the last 5-6 commits to freeorion/freeorion to the new repository version without manually downloading and applying patches and recommitting. One of those fixes CMakeLists.txt so just picking that fixes any issues with it.
I did that by downloading the patches from github via the patch url (like https://github.com/freeorion/freeorion/ ... 7c54.patch mind the patch file extension) and applying them with `git am`.

Currently my repository has the following commits integrated:
master wrote: git am < ../patches/0001-Create-README.md.patch
git am < ../patches/0002-Add-.gitignore-for-common-file-types.patch
git am < ../patches/0003-Add-.gitattributes-to-enforce-eol-style.patch
git am < ../patches/0004-Temporary-git-compatible-version-string-generation.patch
git am < ../patches/0005-Removed-leftover-ogre-script.patch
git am < ../patches/0006-Fixed-issue-with-error-message-about-typing-unsafe-h.patch
git am < ../patches/0007-Added-capacity-stat-for-Specials-with-effect-support.patch
git am < ../patches/0008-Added-iostream-header-to-StringTable.cpp.patch
git am < ../patches/0009-Commented-out-unnecessary-log-message.patch
git am < ../patches/0010-Removed-reference-to-PythonUniverseGenerator.h.patch
git am < ../patches/0011-partial-empireaffiliation-adjustments.patch
git am < ../patches/0012-more-empireaffiliation-adjustments.patch
git am < ../patches/0013-fixed-use-of-new-enum-s-in-empire-affiliation-condit.patch
git am < ../patches/0014-fixed-typo.patch
git am < ../patches/0015-Removed-bad-enum-uses.patch
logging-migration wrote: git am < ../patches/0001-Replaced-log4cpp-with-Boost.Log.patch
git am < ../patches/0002-Removed-log4cpp-code.patch
[1] viewtopic.php?p=70554#p70554
[2] viewtopic.php?p=70556#p70556
Last edited by adrian_broher on Sat Mar 28, 2015 7:35 pm, edited 1 time in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

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

Re: GitHub migration procedure

#154 Post by Vezzra » Sat Mar 28, 2015 7:32 pm

Geoff the Medio wrote:For release branches, isn't the point of them to separate stuff away from the master branch that shouldn't be in master as it is release-specific? Anything that should be merged from release back to master should just be done in master and merged the other way. That said, the use of a branch for the v0.4.4 release was a new procedure, so if that's not how release-specific changes would normally be dealt with on git, then there's no need to do so in future. (A release branch isn't a temporary space to work on a feature... it's a permanent divergence from the master development line.) For the v0.4.4 branch, presumably any important commits can be cherry-picked back to master, as effectively was done for the changelog. Then presumably it should just be left as is.
That's exactly how I feel about release branches. Changes that would need to be merged back into master, should be committed to master in the first place and then merged into the release branch. Things like the changelog being the notable exception to the rule.

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

Re: GitHub migration procedure

#155 Post by adrian_broher » Sat Mar 28, 2015 7:34 pm

Vezzra wrote:
adrian_broher wrote:Anyway, how should we progress now? The only thing that prevents me uploading the new repo is the question about merging release-v0.4.4 or not.
That depends on what "stitching back into master" means - is this just a link you set, so that git describe works, or will actual merging (as in actual changes in master wil happen because of this) be done?
It's a real merge.
Vezzra wrote: If the latter is the case, I'd vote for not to merge, upload the new repo, and we can figure out if we want to merge afterwards, assuming that can be done with a normal git merge. Gives us more time to check more carefully what we actually might want to merge into master from the release branch.
So - from you.

+ = keep merge release-v0.4.4
- = remove merge release-v0.4.4

+ adrian_broher
- Vezzra
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: 12441
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: GitHub migration procedure

#156 Post by Geoff the Medio » Sat Mar 28, 2015 7:39 pm

adrian_broher wrote:I did that by downloading the patches from github via the patch url...
That's what I was asking if I would need to do to port over the patches to the new repository.
logging-migration wrote:git am < ../patches/0001-Replaced-log4cpp-with-Boost.Log.patch
git am < ../patches/0002-Removed-log4cpp-code.patch
Should also have "More log4cpp removal."

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

Re: GitHub migration procedure

#157 Post by Vezzra » Sat Mar 28, 2015 7:40 pm

adrian_broher wrote:For me personally the release branch concept served the purpose of 'slowing down' release development without blocking main branch development. You maybe remember that this was the exact reason why I asked for a release branch in the first place [1][2]. It's to disconnect main development from release development. This allows risky, application breaking changes on the main development branch while the people, who do the release can do sensible cherry picking for bug fix changes.
That's of course a perfectly valid and probably the main reason why you do release branches, and, as you pointed out, was the reason why we tried that experiment with 0.4.4.

However, that doesn't invalidate Geoffs arguments. His point being that only those things should go directly into the release branch instead of to the main dev branch and then be merged into the release branch which are a permanent divergence from the main dev branch, and therefore shouldn't be merged back, making merging things back from release branch to main dev branch the exception, which can and should be cherry picked.

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

Re: GitHub migration procedure

#158 Post by Geoff the Medio » Sat Mar 28, 2015 7:44 pm

Vezzra wrote:However, that doesn't invalidate Geoffs arguments.
I didn't mean to say that that is how things should be done. Rather, I meant that that seemed sensible to me, but if there's a different standard practice on git, we can follow that in future.

That said, it doesn't make much sense to me to merge back release-specific changes. A branch might also have benefits for not halting release-inappropriate development, but presumably it would generally have release specific changes as well...? I may not understand the suggested use for a release branch, though.

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

Re: GitHub migration procedure

#159 Post by Vezzra » Sat Mar 28, 2015 7:47 pm

adrian_broher wrote:So - from you.

+ = keep merge release-v0.4.4
- = remove merge release-v0.4.4

+ adrian_broher
- Vezzra
Pretty much ;)

Although it's not really a decision by majority vote, as the final decision on that is for Geoff to make (being project lead). These "votes" more or less serve the purpose of letting him know what his minions would want. :mrgreen:

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

Re: GitHub migration procedure

#160 Post by Geoff the Medio » Sat Mar 28, 2015 7:49 pm

What I'd like is further clarification of the standard use of branches for releases in git, specifically relating to release-specific changes that wouldn't make sense to merge back to master. I assume there's more reasoning behind what adrian_broher suggests that I haven't read yet.

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

Re: GitHub migration procedure

#161 Post by Vezzra » Sat Mar 28, 2015 7:52 pm

Geoff the Medio wrote:I didn't mean to say that that is how things should be done. Rather, I meant that that seemed sensible to me, but if there's a different standard practice on git, we can follow that in future.
I'm not that knowledgeable on this topic either, but I'd assume that release branch practices aren't necessarily specific to the VCS you use.
That said, it doesn't make much sense to me to merge back release-specific changes. A branch might also have benefits for not halting release-inappropriate development, but presumably it would generally have release specific changes as well...?
I'd say both a good and valid reasons.

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: GitHub migration procedure

#162 Post by MatGB » Sat Mar 28, 2015 7:57 pm

Most of this is way over my head, but for the release branch specifically there were three advantages, one was continued main trunk development, second being release branch specific changes (commenting out super Testers, changing default AI behaviour to beginner), the last allowing for a bugfix release for the current "stable" branch if we felt necessary.

The latter never ended up happening,b ut there were, IIRC, some major issues with a windows specific graphics driver that broke the stable release for some people, I think the SDL migration was in part to fix that but we never did release the bugfix that had been discussed (afraid I forget the specific details, it didn't affect my graphics drivers).

Merging it back in is something I know not the pros and cons of, but I definitely don't want Test releases to not have Super Testers or have the default AI go back to Beginner.
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.

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

Re: GitHub migration procedure

#163 Post by Vezzra » Sat Mar 28, 2015 8:03 pm

Geoff the Medio wrote:What I'd like is further clarification of the standard use of branches for releases in git, specifically relating to release-specific changes that wouldn't make sense to merge back to master.
AFAIK there are two major approaches how to handle release and development branches. The first one is how we did go about it. Master (trunk in svn) is the main dev branch, and when you want to make a release, you create a release branch.

The second one is to have master as the branch that only gets tested, stable features that are ready for release merged into, while development takes place on a dedicated development branch. This development branch would be used as we use master now. Features that have been sufficiently tested and are release ready get merged into master. Once you've accumulated enough new additions to master that you want to do a new release, you tag the tip of master and build a new stable release from it. At least that's how I understood it when I read about these practices in the git tutorials.

User avatar
Dilvish
AI Lead, Programmer
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: GitHub migration procedure

#164 Post by Dilvish » Sat Mar 28, 2015 8:05 pm

If I'm understanding correctly (a nontrivial if), then it seems like Geoff and Vezzra don't have significant substantive concerns about Marcel's proposal specifically with regards to the 0.4.4 branch, but have been mostly wanting, more as a procedural matter, to determine what our Release treatment will be going forward, and would then prefer that the 0.4.4 branch be handled in the same (or most compatible) manner. If that's the case, then I would suggest we give more weight to expediency, allow Marcel to wrap up the import with his proposed treatment of 0.4.4, and give ourselves some more breathing space to determine our procedure for later releases.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

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

Re: GitHub migration procedure

#165 Post by adrian_broher » Sat Mar 28, 2015 8:07 pm

Geoff the Medio wrote:What I'd like is further clarification of the standard use of branches for releases in git, specifically relating to release-specific changes that wouldn't make sense to merge back to master.
There is no exact way git enforces or even suggests how to handle release branches. The decision itself how to or not to do release branches right/at all is up the specific project. The opinions I mentioned so far are just, well, my opinions. And I'm honest here: I'm stating my experience with projects, that are/were smaller than FreeOrion in size and number of committers, but they served me well so far. It can be very true that these experiences just don't work for FreeOrion. But that's something only time can tell.
Geoff the Medio wrote:I assume there's more reasoning behind what adrian_broher suggests that I haven't read yet.
This is a bit offtopic, but I can tell you my point of view here. I generally have the feeling (and yes, it's mainly a gut feeling without any hard facts supporting it) that when we (or any other software development team) need release-specific changes we failed at some point in designing the application or build system properly. In my opinion every commit should be (in theory, practice shows that this isn't possible) a potential release or release candidate, mind the lurking bugs of course. When we need to prepare the software in any way to make it release ready, this excludes squashing bugs, this also means that theses steps need to be repeated on every release properly, which is just another point of potential failure. And the other commits are things, bug fixes and updated documentation, that should and must be shared between the main development branch and the release branch. So merging back release branches only seems a sensible choice to me.
Last edited by adrian_broher on Sat Mar 28, 2015 11:07 pm, edited 1 time in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

Post Reply