[Glestae-devel] Merge of GAE and MG

[Frank Tetzel <te...@us...>]

Hi all,

seems like i have the privilege to get the ball rolling. So welcome MG devs. 

How do we get the merge started? I like the idea of softcoder who proposed to 
make a release of each fork in the near future. That makes sure our codebases 
are stable and we don't have any half-baken experimental stuff in it. 
Everything which wasn't released should be applied after the merge. So better 
don't start any big stuff for the next release, just finish up what you already 
started. I think the end of march would be a nice deadline (maybe a bit too 
far away). Gives us enough time to get it stable.

In the meantime we should probably talk about shared_lib as that's the first 
step in the merge. What was changed in shared_lib by each fork?

I'm probably the wrong person to ask when it comes to GAE as i don't know what 
was changed before i joined and i haven't worked that much on it. Two big 
things i know about are Physfs and TinyXml.

TinyXml replaced xerces-c as xml parser but i think it still uses the same or 
very similar interface on the glest side. So that shouldn't be a problem. 
Ofcourse the question is: Do we want to have tinyxml? The benefit i see: It's 
much smaller. It might be quicker but i haven't measured it. Negative aspects: 
Upstream development seems to be dead and it's not avaible in most package 
archives. That's why we have a copy in our codebase.

I integrated physfs, so i'm the one to ask about it. Physfs is a virtual 
filesystem which makes handling files at different locations very easy. We can 
now easily install on unix systems and have addon handling. I needed to change 
every file operation to go through physfs. I used a factory because tools like 
the map editor need to disable physfs as it doesn't support absolute paths (it 
could on linux by mounting root, but windows doesn't have a root). So i needed 
to touch many files but i think it was worth it.

I'm currently working on an addon manager for downloading and updating addons 
as a separate wxWidgets program. It doesn't link against shared_lib, just 
needs physfs in glest to be useful. Should be ready for next release.

Regards,
Frank aka Yggdrasil.

Re: [Glestae-devel] Merge of GAE and MG

[Michael Speth <co...@gm...>]

Greetings,
  Has it been decided to use git or svn for the main repo?  I think git
would be a better tool for merging these 2 projects since it has really good
merge tools.  git could also keep all of the revision history for all 4
projects (vanilla Glest, GAE, MG, and Glest 4).

I currently have a git repo that has MG on my own machine and various
branches of MG uploaded to GIS's sourceforge git repo.  It was fairly easy
to get MG compiling and running once pulled from svn (just have to change a
few lines in the cmake file).

Is it a good idea to have all 4 projects in 1 repo?  Or once merged, ditch
the history of the previous projects and just maintain Glest 4 (or whatever
title comes out)?

On Thu, Feb 24, 2011 at 7:38 PM, Frank Tetzel <te...@us...
> wrote:

> Hi all,
>
> seems like i have the privilege to get the ball rolling. So welcome MG
> devs.
>
> How do we get the merge started? I like the idea of softcoder who proposed
> to
> make a release of each fork in the near future. That makes sure our
> codebases
> are stable and we don't have any half-baken experimental stuff in it.
> Everything which wasn't released should be applied after the merge. So
> better
> don't start any big stuff for the next release, just finish up what you
> already
> started. I think the end of march would be a nice deadline (maybe a bit too
> far away). Gives us enough time to get it stable.
>
> In the meantime we should probably talk about shared_lib as that's the
> first
> step in the merge. What was changed in shared_lib by each fork?
>
> I'm probably the wrong person to ask when it comes to GAE as i don't know
> what
> was changed before i joined and i haven't worked that much on it. Two big
> things i know about are Physfs and TinyXml.
>
> TinyXml replaced xerces-c as xml parser but i think it still uses the same
> or
> very similar interface on the glest side. So that shouldn't be a problem.
> Ofcourse the question is: Do we want to have tinyxml? The benefit i see:
> It's
> much smaller. It might be quicker but i haven't measured it. Negative
> aspects:
> Upstream development seems to be dead and it's not avaible in most package
> archives. That's why we have a copy in our codebase.
>
> I integrated physfs, so i'm the one to ask about it. Physfs is a virtual
> filesystem which makes handling files at different locations very easy. We
> can
> now easily install on unix systems and have addon handling. I needed to
> change
> every file operation to go through physfs. I used a factory because tools
> like
> the map editor need to disable physfs as it doesn't support absolute paths
> (it
> could on linux by mounting root, but windows doesn't have a root). So i
> needed
> to touch many files but i think it was worth it.
>
> I'm currently working on an addon manager for downloading and updating
> addons
> as a separate wxWidgets program. It doesn't link against shared_lib, just
> needs physfs in glest to be useful. Should be ready for next release.
>
> Regards,
> Frank aka Yggdrasil.
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Glestae-devel mailing list
> Glest...@li...
> https://lists.sourceforge.net/lists/listinfo/glestae-devel
>



-- 
Michael Speth  石雨濛
Computer Engineer

Re: [Glestae-devel] Merge of GAE and MG

[titus tscharntke <titus...@ya...>]

Hi, 

I think we should start with a much more general discussion:
We should meet in irc ( or do we have any kind of web pad ?) and talk about very 
general questions before we start with these technical discussion:
- Do we have a somehow common vision for glest? Which targets does each MG/GAE 
member have.
- Which motivation does each one has to work on glest?

followed by:
- Which things (features/technical solutions and so on )) are important for each 
member? What is not so important. Which conflicts do we see?
- Which unique (finished!) features do we have in MG/GAE and which of them do we 
want to see in a common glest? ( not too detailed of course! )

And then the ultimate question:
How can a merge be done technically? For example using MG as a base? Or GAE as a 
base? Or a complete new instance?
... and after this we can start to talk about things like GIT/SVN, glest lib and 
so on.

________________________________

In reply to the GIT/SVN discussion:
I cannot really talk about the right version control system because I  don't 
know GIT. I just want to mention that svn tools are much more  widely available 
and GIT is maybe not really THE ultimate tool for  windows. ( I use linux :-) ) 
. I also like the fact that I can browse  SVN via webinterface on sourceforge 
and so on. But as I said, I don't  know much about GIT yet.
The better question is, do we really need a new repository? Just from my  point 
of view its obvious that we use one of both forks as the base  thing and merge 
in the things we need from the other one.

Titus ( aka titi )

Re: [Glestae-devel] Merge of GAE and MG

[Mark Vejvoda <mark_...@ho...>]

If we can agree on the following, this could be a start, please offer
edits, additions or deletions, this is just meant as a starting point:

#1. We prefer to use simple, standardized tools and libs (thus making
adoption on many platforms and distros widely possible) as well as cross
platform accessibility more viable.

#2. We commit to supporting both single and network play on at least
Linux and Windows (and preferably on BSD and Mac if others are willing
to work with us)

#3. We commit to always having a stable, high quality stream of code
that we can point people to at any given point in time.

#4. We only promote new code to the stable stream if a) we have done
reasonable testing in the test branch and b) we are willing to commit
time and effort to "See the code promotion through" in the stable
branch, meaning closely monitor and fix issues for at least the first
week of the code going into the stable branch.

#5. We commit to some standardized way to log and report errors both in
debug and release versions in order to track down problems as easily as
possible. (details may be discussed, this is just the principle)

#6. We respect there are different ways to write code and share
different views in a respectful manner.

#7. We agree to put prejudice aside and attempt to select the duplicated
parts of code (between both projects) and use the most suitable part
given the above goals. Take into account, code complexity, cleanness and
stability.


On Thu, 2011-02-24 at 15:55 +0000, titus tscharntke wrote:
> Hi, 
> 
> I think we should start with a much more general discussion:
> We should meet in irc ( or do we have any kind of web pad ?) and talk
> about very general questions before we start with these technical
> discussion:
> - Do we have a somehow common vision for glest? Which targets does
> each MG/GAE member have.
> - Which motivation does each one has to work on glest?
> 
> followed by:
> - Which things (features/technical solutions and so on )) are
> important for each member? What is not so important. Which conflicts
> do we see?
> - Which unique (finished!) features do we have in MG/GAE and which of
> them do we want to see in a common glest? ( not too detailed of
> course! )
> 
> And then the ultimate question:
> How can a merge be done technically? For example using MG as a base?
> Or GAE as a base? Or a complete new instance?
> ... and after this we can start to talk about things like GIT/SVN,
> glest lib and so on.
> 
> 
> ______________________________________________________________________
> 
> In reply to the GIT/SVN discussion:
> I cannot really talk about the right version control system because I
> don't know GIT. I just want to mention that svn tools are much more
> widely available and GIT is maybe not really THE ultimate tool for
> windows. ( I use linux :-) ) . I also like the fact that I can browse
> SVN via webinterface on sourceforge and so on. But as I said, I don't
> know much about GIT yet.
> The better question is, do we really need a new repository? Just from
> my point of view its obvious that we use one of both forks as the base
> thing and merge in the things we need from the other one.
> 
> Titus ( aka titi )
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________ Glestae-devel mailing list Glest...@li... https://lists.sourceforge.net/lists/listinfo/glestae-devel

Re: [Glestae-devel] Merge of GAE and MG

[titus tscharntke <titus...@ya...>]

Hi, here is one very important thing for me:
I don't want to make just an engine, I want to make a fun game which works in 
linux! There are several engines and cool ideas which were made in linux and are 
available in Linux. But whats missing the most in Linux are games which really 
reach the state of beeing playable and which are fun to play for a long time! 
This is what I have in mind. I want to make a game which is complete ( 
data/engine/gameplay ).
Beside of this I also want to make it customizable but my intention is not just 
to build (another) super flexible enginge which can ( theoretically ) be used to 
create cool mods/games! My focus is clearly to create a ready to play game ( 
including a lot of game data content! ) ! 




About the IRC-meeting, please all use the following link to find the right 
moment!
Please really mark all times when you can make it possible to join.
http://doodle.com/pqg4ziubrgam34dk
If the time is very bad in general for someone, please suggest another time, so 
we can start another poll.

titi



________________________________
Von: Mark Vejvoda <mark_...@ho...>
An: glest...@li...
Gesendet: Donnerstag, den 24. Februar 2011, 18:13:25 Uhr
Betreff: Re: [Glestae-devel] Merge of GAE and MG

If we can agree on the following, this could be a start, please offer
edits, additions or deletions, this is just meant as a starting point:

#1. We prefer to use simple, standardized tools and libs (thus making
adoption on many platforms and distros widely possible) as well as cross
platform accessibility more viable.

#2. We commit to supporting both single and network play on at least
Linux and Windows (and preferably on BSD and Mac if others are willing
to work with us)

#3. We commit to always having a stable, high quality stream of code
that we can point people to at any given point in time.

#4. We only promote new code to the stable stream if a) we have done
reasonable testing in the test branch and b) we are willing to commit
time and effort to "See the code promotion through" in the stable
branch, meaning closely monitor and fix issues for at least the first
week of the code going into the stable branch.

#5. We commit to some standardized way to log and report errors both in
debug and release versions in order to track down problems as easily as
possible. (details may be discussed, this is just the principle)

#6. We respect there are different ways to write code and share
different views in a respectful manner.

#7. We agree to put prejudice aside and attempt to select the duplicated
parts of code (between both projects) and use the most suitable part
given the above goals. Take into account, code complexity, cleanness and
stability.


On Thu, 2011-02-24 at 15:55 +0000, titus tscharntke wrote:
> Hi, 
> 
> I think we should start with a much more general discussion:
> We should meet in irc ( or do we have any kind of web pad ?) and talk
> about very general questions before we start with these technical
> discussion:
> - Do we have a somehow common vision for glest? Which targets does
> each MG/GAE member have.
> - Which motivation does each one has to work on glest?
> 
> followed by:
> - Which things (features/technical solutions and so on )) are
> important for each member? What is not so important. Which conflicts
> do we see?
> - Which unique (finished!) features do we have in MG/GAE and which of
> them do we want to see in a common glest? ( not too detailed of
> course! )
> 
> And then the ultimate question:
> How can a merge be done technically? For example using MG as a base?
> Or GAE as a base? Or a complete new instance?
> ... and after this we can start to talk about things like GIT/SVN,
> glest lib and so on.
> 
> 
> ______________________________________________________________________
> 
> In reply to the GIT/SVN discussion:
> I cannot really talk about the right version control system because I
> don't know GIT. I just want to mention that svn tools are much more
> widely available and GIT is maybe not really THE ultimate tool for
> windows. ( I use linux :-) ) . I also like the fact that I can browse
> SVN via webinterface on sourceforge and so on. But as I said, I don't
> know much about GIT yet.
> The better question is, do we really need a new repository? Just from
> my point of view its obvious that we use one of both forks as the base
> thing and merge in the things we need from the other one.
> 
> Titus ( aka titi )
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________ Glestae-devel mailing list 
>Glest...@li... 
>https://lists.sourceforge.net/lists/listinfo/glestae-devel



------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Glestae-devel mailing list
Glest...@li...
https://lists.sourceforge.net/lists/listinfo/glestae-devel

Re: [Glestae-devel] Merge of GAE and MG

[Nathan Turner <hails...@us...>]

I agree with all of Mark's points. Also I think the most conflicts
will be in gameplay (and presentation) related decisions. This is why
I think it's important to separate engine and gameplay code
(preferably into lua). I like to focus more on adding features for
modders so they can make the decisions of how to make a good game.

I think we should use GIT (see "Re: [Glestae-devel] + git - svn" in
the mailing list archives). It's more suited to branching/merging and
works well on Windows.

For the IRC meeting poll the time comes out as 8am which is doable but
I've got into the habit of staying up late and waking up late so
there's no guarentee I'll be awake.

Other than that basically what I posted on the forums (
http://glest.org/glest_board/index.php?topic=6577.msg67610#msg67610 ).

On 25 February 2011 20:54, titus tscharntke <titus...@ya...> wrote:
> Hi, here is one very important thing for me:
> I don't want to make just an engine, I want to make a fun game which works
> in linux! There are several engines and cool ideas which were made in linux
> and are available in Linux. But whats missing the most in Linux are games
> which really reach the state of beeing playable and which are fun to play
> for a long time! This is what I have in mind. I want to make a game which is
> complete ( data/engine/gameplay ).
> Beside of this I also want to make it customizable but my intention is not
> just to build (another) super flexible enginge which can ( theoretically )
> be used to create cool mods/games! My focus is clearly to create a ready to
> play game ( including a lot of game data content! ) !
>
>
> About the IRC-meeting, please all use the following link to find the right
> moment!
> Please really mark all times when you can make it possible to join.
> http://doodle.com/pqg4ziubrgam34dk
> If the time is very bad in general for someone, please suggest another time,
> so we can start another poll.
>
> titi
>
> ________________________________
> Von: Mark Vejvoda <mark_...@ho...>
> An: glest...@li...
> Gesendet: Donnerstag, den 24. Februar 2011, 18:13:25 Uhr
> Betreff: Re: [Glestae-devel] Merge of GAE and MG
>
> If we can agree on the following, this could be a start, please offer
> edits, additions or deletions, this is just meant as a starting point:
>
> #1. We prefer to use simple, standardized tools and libs (thus making
> adoption on many platforms and distros widely possible) as well as cross
> platform accessibility more viable.
>
> #2. We commit to supporting both single and network play on at least
> Linux and Windows (and preferably on BSD and Mac if others are willing
> to work with us)
>
> #3. We commit to always having a stable, high quality stream of code
> that we can point people to at any given point in time.
>
> #4. We only promote new code to the stable stream if a) we have done
> reasonable testing in the test branch and b) we are willing to commit
> time and effort to "See the code promotion through" in the stable
> branch, meaning closely monitor and fix issues for at least the first
> week of the code going into the stable branch.
>
> #5. We commit to some standardized way to log and report errors both in
> debug and release versions in order to track down problems as easily as
> possible. (details may be discussed, this is just the principle)
>
> #6. We respect there are different ways to write code and share
> different views in a respectful manner.
>
> #7. We agree to put prejudice aside and attempt to select the duplicated
> parts of code (between both projects) and use the most suitable part
> given the above goals. Take into account, code complexity, cleanness and
> stability.
>
>
> On Thu, 2011-02-24 at 15:55 +0000, titus tscharntke wrote:
>> Hi,
>>
>> I think we should start with a much more general discussion:
>> We should meet in irc ( or do we have any kind of web pad ?) and talk
>> about very general questions before we start with these technical
>> discussion:
>> - Do we have a somehow common vision for glest? Which targets does
>> each MG/GAE member have.
>> - Which motivation does each one has to work on glest?
>>
>> followed by:
>> - Which things (features/technical solutions and so on )) are
>> important for each member? What is not so important. Which conflicts
>> do we see?
>> - Which unique (finished!) features do we have in MG/GAE and which of
>> them do we want to see in a common glest? ( not too detailed of
>> course! )
>>
>> And then the ultimate question:
>> How can a merge be done technically? For example using MG as a base?
>> Or GAE as a base? Or a complete new instance?
>> ... and after this we can start to talk about things like GIT/SVN,
>> glest lib and so on.
>>
>>
>> ______________________________________________________________________
>>
>> In reply to the GIT/SVN discussion:
>> I cannot really talk about the right version control system because I
>> don't know GIT. I just want to mention that svn tools are much more
>> widely available and GIT is maybe not really THE ultimate tool for
>> windows. ( I use linux :-) ) . I also like the fact that I can browse
>> SVN via webinterface on sourceforge and so on. But as I said, I don't
>> know much about GIT yet.
>> The better question is, do we really need a new repository? Just from
>> my point of view its obvious that we use one of both forks as the base
>> thing and merge in the things we need from the other one.
>>
>> Titus ( aka titi )
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Free Software Download: Index, Search & Analyze Logs and other IT data in
>> Real-Time with Splunk. Collect, index and harness all the fast moving IT
>> data
>> generated by your applications, servers and devices whether physical,
>> virtual
>> or in the cloud. Deliver compliance at lower cost and gain new business
>> insights. http://p.sf.net/sfu/splunk-dev2dev
>> _______________________________________________ Glestae-devel mailing list
>> Glest...@li...
>> https://lists.sourceforge.net/lists/listinfo/glestae-devel
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Glestae-devel mailing list
> Glest...@li...
> https://lists.sourceforge.net/lists/listinfo/glestae-devel
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Glestae-devel mailing list
> Glest...@li...
> https://lists.sourceforge.net/lists/listinfo/glestae-devel
>
>

Re: [Glestae-devel] Merge of GAE and MG

[James McCulloch <si...@gm...>]

I too can agree to all of Mark's points, the details of several will
need to be fleshed out, but for now I think we should clear up the
'What do you want?' question.

On Fri, Feb 25, 2011 at 9:54 PM, titus tscharntke
<titus...@ya...> wrote:
> Hi, here is one very important thing for me:
> I don't want to make just an engine, I want to make a fun game which works
> in linux! There are several engines and cool ideas which were made in linux
> and are available in Linux. But whats missing the most in Linux are games
> which really reach the state of beeing playable and which are fun to play
> for a long time! This is what I have in mind. I want to make a game which is
> complete ( data/engine/gameplay ).

This is where we obviously need to compromise, I want to make an
engine.  I also am taking part in some mod development now, and so
maybe I want to help make a game too, but that game is not MegaGlest,
it's Constellus.

If we are to work together then we need to be clear about what we are
working together on. A strategy game engine.

Despite the diffrence in our ultimate goals, there is no reason for us
not to work together. Many features can simply be ignored by the
modder/game maker if they don't want them (ie, new commands), and for
other things (ie, auto-repair) we can make it optional, perhaps set in
the tech xml.

I too think git is the way to go forward and, as I mentioned in the
initial IRC conversation with softcoder, that the project could/should
be code only, with data provided as a git sub-module. This way, Titi
can use the MegaGlest submodule, I can use Constellus, Michael Speth
can have GIS, Chuppa can have MRise, Omega Military, etc, etc, etc.

Preferably everyone uses the same engine code, obviously things will
often be developed for one or more of these projects in isolation and
will then result in a 'pull request' (in git parlaence). If anyone
objects to the features implemented/changed, then we can resolve the
issue by simply making it optional, or 'switchable' (ie. could be done
in two or more ways, the mod maker choses).

I think this is a reasonable plan, and perhaps the only way we can
make this work. I know Titi and I disagree on a lot of game-play
aspects, so I think something like the above 'conflict resolution'
stategy would need to be adopted.

So... at this stage I think we need to know where everyone is at.

1. Despite your own ultimate goal/aim in working on Glest, are you
willing to work on an engine that many people are using to make
strategy games with?

2. Does the git 'code repository' with data sub-modules appeal?

3. Are you willing to do the work required to make new features you
have developed optional if someone objects to them?

and I might as well start, yes, yes and yes.

Cheers,
 - James (aka silnarm)

Re: [Glestae-devel] Merge of GAE and MG

[ultifd <ul...@gm...>]

Don't you mean FPM?

On Sat, Feb 26, 2011 at 12:26 AM, James McCulloch <si...@gm...> wrote:
>This is where we obviously need to compromise, I want to make an
>engine.  I also am taking part in some mod development now, and so
>maybe I want to help make a game too, but that game is not MegaGlest,
>it's Constellus.

Re: [Glestae-devel] Merge of GAE and MG

[titus tscharntke <titus...@ya...>]

Hi, 
yes I think the idea to make things configurable which raise conflicts is very 
good and I wanted to suggest this too.
With this I can agree to a lot more things! ( many of these are techtree 
specific then  ).

To have separated sources might be ok for the beginning, but I think it should 
be a target that we all use the same code one day.
One vision would  be a base installation which includes an ingame 
download/installation  where you can choose all the games/mods which are 
available ( and maybe approved by us ).

Regarding the times in doodle where we can meet, I think on weekends its also 
possible to meet 2 hours later!

Titus

Re: [Glestae-devel] Merge of GAE and MG

[Frank Tetzel <te...@us...>]

> To have separated sources might be ok for the beginning, but I think it
> should be a target that we all use the same code one day.
> One vision would  be a base installation which includes an ingame
> download/installation  where you can choose all the games/mods which are
> available ( and maybe approved by us ).

There shouldn't be separate codebases. What James probably meant are clones of 
the mainline repo to implement some new features, stabilize it there, later 
ask for review and get it merged back. Similar to feature branches in svn.

This is only real needed for people which are not part of the dev group or 
when we use the gatekeeper workflow.
http://whygitisbetterthanx.com/#any-workflow
(called integration manager there)

I'm no fan of gatekeeper. We should just use one shared repo and use feature 
branches there like in svn. Still other devs might create public clones to 
create their patches and later make a pull request. It's better than a patch 
file as you also get the history how this patch was created.

I'm not sure about the data submodules. I don't expect the modders to use git 
and i like to have some base data to test new features out.

Btw, i don't care why someone is working on glest. You can't expect that 
everyone shares a common vision and it doesn't make coding easier or anything. 
We should decide every individual case. How we want this feature added.

Regards,
Frank.

Re: [Glestae-devel] Merge of GAE and MG

[James McCulloch <si...@gm...>]

On Sun, Feb 27, 2011 at 10:15 PM, Frank Tetzel
<te...@us...> wrote:
> There shouldn't be separate codebases. What James probably meant are clones of
> the mainline repo to implement some new features, stabilize it there, later
> ask for review and get it merged back. Similar to feature branches in svn.

This indeed was what I meant, I don't want us to have separate code,
the core team should
all use the same git remote and work together (in branches mostly).

The obvious example is the current situation with MG and GIS, git
would make it make easier
for Michael to maintain his changes with an ever evolving up-stream
code base, indeed he
is doing this already, by funnelling your SVN repo through a GIT repo,
a step he would now
be able to cut out completely.

> I'm not sure about the data submodules. I don't expect the modders to use git
> and i like to have some base data to test new features out.

Good point, Nathan also raised some concerns about it ease of use, so
if we were going
to do this, it would probably be best to try it out first.

Cheers,
 - James