[Kde-scm-interest] Layout of the Git repositories for KDE (proposal #2)

[Johannes Sixt]

Riccardo Iaconelli schrieb:
> By the way, given that most of the development should happen into projects/, 
> how are we going to make sure that developers can easily apply cross-module 
> changes to the repo in projects?
> Take an example:
> Someone does a big api change, and does all the porting necessary to all KDE/. 
> He does a cross-module commit, with both the api change, and all the 
> applications ported to the new stuff.
> The maintainer, of, for example, kig, has a projects/kig.git repo, where he 
> does most of the work. As the crossmodule commit has been done on the 
> kdeedu.git, how can he backport the change to kig easily and apply it to the 
> code in projects/, so he can continue to work happily?

He does not *back* port the cross-module change to kig, but he must 
*forward* port kig to the new API. The workflow could be like this:

1. $maintainer happily *completes* a feature in a well-known environment 
(read: with a specific API).

2. $maintainer decides it's time to integrate with latest KDE developments; 
notices that API is meanwhile outdated.

3. $maintainer updates the environment to latest version. This must happen 
somehow outside his local clone of the project. I.e. downloads (git-pull) 
KDE.git, kdelibs, kdebase, etc., but *not* kig, compiles installs. New 
environment is ready.

4. In the local clone of kig that contains new features:

	git pull stable

(assuming 'stable' was set up to point to the proposed stable/ hierarchy, 
which should include kig). This pulls in the API changes that $Someone had 
applied to kig.

5. Fix conflicts, git commit, fix API changes in the new parts that exist 
only locally, git commit.

6. git push stable

-- Hannes