[[toc]]

• Project Name

Split Git Repo into individual components.

++ Bugs

N/A

++ People

All developers.

++ Description

From dev mailing list:

Going to try to sum up what I think is forming as a consensus.

Moving applications and framework packages to separate repos seems to be the most supported idea.

• GitHub allows unlimited public repos, so we are good there
• Can maintain all history. See https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo
• Might be a bit more unwieldy to work with (current monolithic repo allows commits across applications; but it might be a good thing to require different commits for each application for a more granular approach at adding features/fixing bugs.)

Talk of using git subtree(?)

• http://log.pardus.de/2012/08/modular-git-with-git-subtree.html
• However, this approach seems to completely neglect the current issue of "what should the master branch be?" or whether this question can even be properly solved when dealing with so many disparate pieces

Worries about scripting to setup repos

• Argument was made that it only takes 2 lines currently to create an installation.
• However recent discussion on mailing list pointed out it is extremely difficult for non-developers to set up an installation using git. So the current scripts aren't perfect by any means.
• Additionally, whatever way we switch to will also need to be scripted so we would be in no different place than we are currently.
• No solution is going to work out-of-the-box.
• Use PHP Composer to help automate the process of generating a usable build from git (http://getcomposer.org/).

...

And the last time I chatted with Nils about composer it didn't have support for the installation of web assets - so for Horde the result would be a mixture of using composer and PEAR package definitions. I have no clue how much work it would be to get composer on par with PEAR in that area. Nils suggested that this should not be too hard. But the components helper we have should also be capable of managing PEAR and composer package definitions in parallel.
I would assume we would do something like maintain package.xml files and then use the components script to create a composer.json file. We could probably leverage this code:

https://github.com/claylo/conductor

BTW, adding yet another advantage to separate repositories: this greatly simplifies/improves continuous integration reporting. Not only does this drastically take the time to check a commit, it more directly targets the actual changes the commit made.

++ Resources

...

Back to the ((Projects|Project List))