[dev] Git repo splitting

[Michael J Rubinsky]

Quoting Michael M Slusarz <slusarz at horde.org>:

> 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.

IMO, the developer checkout/setting up the working directories etc...  
are THE most critical thing to get right before we officially split.

> 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.

For me, having it on dev.horde.org was a nice psychological security  
blanket - knowing we had full control over everything, knowing we had  
a "backup" repo on github, keeping a level of separation between our  
active repo and the "public" one. That being said, I think given our  
limited resources it makes a lot of sense to move completely to github.

> 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.

I'm slightly torn about this one. It makes sense if we go to github  
for our master repo to just move everything. OTOH, I'm not ready to  
abandon Whups as a product. Moving away from it will send a message  
that we don't thing it's worth using. More practically, I'm wondering  
how easy it would be to do things like move a ticket from one "queue"  
to another on GitHub. As we all know, there are plenty of times that  
tickets are created under the wrong queue. Also, there are some  
queues, like the Synchronization queue that would span multiple repos.  
It's nice having the ability to create queues on-demand that satisfy  
some need.


-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5869 bytes
Desc: S/MIME Signature
URL: <http://lists.horde.org/archives/dev/attachments/20140816/11c74bd0/attachment.bin>