[dev] Git repo splitting

[Michael M Slusarz]

Now that the x.2 releases have been made, and several months of  
bugfixes have occurred, we need to turn our attention to starting to  
plan the git repo split.

The straw that broke the camels back (or at least my back) is that as  
of right now Travis is completely unusable - at least from a practical  
perspective.  You make a small change in Horde_Foo, and Travis returns  
an error because of a completely unrelated SQL error in Horde_Bar.   
This error may very well be tied into the fact that we are running  
such a monster PHPUnit test that is stressing their setup too badly.   
(Another issue: I commit something that breaks Horde_Foo. Other devs  
should not have to worry about this broken behavior if they later  
commit something to Horde_Bar).

So this is brainstorming on the proper path to do this.

I have (mostly) finished the script necessary to do the actual  
splitting of any given repository.  It correctly filters the repo and  
transfers all tags - and it rewrites the tags to the form used by  
Composer.  Currently it only transfers the master branch.  Need to add  
support so that applications automatically keep FRAMEWORK_* branches  
also.  And add option to allow additional branches to be kept since we  
have a few of those lying around.

I'm really not too concerned about developer checkout.  We can  
worry/talk about things like git subtree later IMHO.  The most  
important tool will be something to update all git repos at once, but  
this is something that can be written in 5 minutes.  And even that is  
not critical.

I'm picturing a base "horde-development" git project that will host  
scripts/tools.  We just keep a static file of libraries/apps in there.

Updating horde-components is more important.  Shouldn't be any  
problems regarding packaging layout, since it already works on a  
per-directory basis.  The composer module will need to be altered  
though to change composer install location from pear.horde.org to our  
packagist install location.

E-mails are probably the biggest change.  This kind of hinges on  
whether we want to use GitHub as our official repository.  If so, we  
push to github - you can set up hooks there to trigger remote events  
on a push action.  So we would still need to run a mail server to send  
these messages.  But I'm probably a +1 on eliminating the need for our  
"master" repository to run on dev.horde.org - although I'm not going  
to fight too hard if others disagree on this point.

Same thing with GitHub's bug reporting.  As someone who has zero time  
or interest to contribute to Whups, I have no problems using github's  
built in reporting.  In my view, that is just one less thing to have  
to worry about from an admin perspective.  Again - I'm not going to  
fight if others disagree and/or have a more personal stake in  
continuing to use Whups.

Testing setups will probably need to change a bit.  Each repo is going  
to need their own travis config file.  Probably want to switch over to  
composer to bring in the dependencies for each individual library.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]