[dev] Git repo splitting

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

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

So, do I understand correctly that the tag names are rewritten, but  
the branch names keep the same?

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

Yes, I agree.

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

We should rather use horde-support for that. Maybe split  
developer-tools from maintainer-tools, or simply rename it. That's  
where the repo-split script should go too btw.

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

Should be simple enough.

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

I'm all for sticking with GitHub for the repository hosting *completely*.

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

I'm torn too exactly for the same reasons. I tend to stick with Whups though.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject