Re: Git repo splitting

On 16.08.2014 17:43, Michael J Rubinsky wrote:
> 
> Quoting Michael M Slusarz <[email protected]>:
> 
>> 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.


The github ticket thing is very centered on development itself. It
doesn't fit well into a consumer/user perspective compared to whups.
This may or may not be what you want.

-- 
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: [email protected]
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

-- 
dev mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlPw4RoACgkQCs1dsHJ/X7BpKQCfUveSlFIYVoUWz6psK6Fh9DAF
ojkAn2KlJAb0nFo1F7j1EzoJZOypK2UF
=zLqT
-----END PGP SIGNATURE-----