[dev] [commits] Horde branch mnemo_4_1 updated. 7324877f91d83f8de26d41ba7ca05be559255994

Wed Mar 27 16:02:00 UTC 2013

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

> Quoting Ben Klang <bklang at horde.org>:
>
>> On Mar 27, 2013, at 9:50 AM, Michael J Rubinsky <mrubinsk at horde.org> wrote:
>>
>>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Vilius Šumskas <vilius at lnk.lt>:
>>>>
>>>>> Michael J Rubinsky <mrubinsk at horde.org> rašė:
>>>>>
>>>>>> Quoting Ben Klang <bklang at horde.org>:
>>>>>>
>>>>>>> On Mar 26, 2013, at 5:13 PM, Michael J Rubinsky
>>>>>>> <mrubinsk at horde.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>>>>>
>>>>>>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>>>>>>
>>>>>>>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>>>>>>>
>>>>>>>>>>> I still think we need to look at making master the git HEAD
>>>>>>>>>>> branch and having "release" branches.  This helps with merge
>>>>>>>>>>> conflicts since those who commit a general fix to the release
>>>>>>>>>>> branch also have to concurrently commit such a fix to the
>>>>>>>>>>> master branch, and they are in the best position to resolve
>>>>>>>>>>> merge conflicts rather than having a later committer try to
>>>>>>>>>>> figure this out later.  This would also enforce the fact that
>>>>>>>>>>> only bug fixes should go into the release branch, since its a
>>>>>>>>>>> PITA to have to make multiple commits if you are developing
>>>>>>>>>>> something that is a new feature instead.
>>>>>>>>>>
>>>>>>>>>> Those are good points pro your argumentation for a different
>>>>>>>>>> branching model.
>>>>>>>>
>>>>>>>>> More points:
>>>>>>>>> - Currently, we have all sorts of topic branches for the x.1
>>>>>>>>> versions.  But this means that changes to each individual topic
>>>>>>>>> branch are probably not being tested by others.  I pretty much
>>>>>>>>> run imp_6_1 myself, but I don't get a chance to test turba_4_1
>>>>>>>>> at all - I'm just switching to it, committing, and then
>>>>>>>>> switching back.  For total code coverage, it sort of makes
>>>>>>>>> sense if us developers are testing all next-generation versions
>>>>>>>>> at this point, rather than dumping them all into a common
>>>>>>>>> branch a month before releasing.
>>>>>>>>
>>>>>>>> I've been running on a local branch, that I merge all the x.1
>>>>>>>> branches into. In fact, I've been developing directly against
>>>>>>>> this local branch and either switching branches or
>>>>>>>> cherry-picking the commits into the correct topic branch before
>>>>>>>> pushing, depending on the number of commits/changes involved.
>>>>>>>>
>>>>>>>> I just use a short shell script to manage the checkout, pulling
>>>>>>>> and merging of the upstream topic branches into my combined
>>>>>>>> branch. It was a major pita at first, but I've gotten to like
>>>>>>>> this approach since it makes it easy to test not only all of the
>>>>>>>> cutting edge code against each other, but also to test the x.1
>>>>>>>> changes of an individual package against the rest of the x.0
>>>>>>>> stable code to assure there are no BC breaking surprises.
>>>>>>>>
>>>>>>>>> - An increasing presence for those wanting to look at the
>>>>>>>>> latest features/advancements in IMP is our page on github.  As
>>>>>>>>> it stands now, you go to that page and it sort of looks like
>>>>>>>>> progress has stagnated/slowed since the release of H5 (since
>>>>>>>>> master is always the default branch shown).  That couldn't be
>>>>>>>>> farther from the truth.  And there is very little indication
>>>>>>>>> that the current x.1 topic branches are important.  After all -
>>>>>>>>> H4-Icalendar branch appears much more prominently than
>>>>>>>>> horde_5_1, for e
>>>>>>>>
>>>>>>>> An interesting point, but not an argument in and of itself for
>>>>>>>> switching our branching model. We shouldn't let Github's UI
>>>>>>>> dictate how we organize our repository.
>>>>>>>
>>>>>>> Not dictate, no, but I'd like to make the point that Github
>>>>>>> brings a lot of visibility to a project.  If it doesn't cause a
>>>>>>> negative impact to our workflow, I think there is value in making
>>>>>>> our activity visible there.  Github is fantastic for turning bug
>>>>>>> reporters into contributors, largely by way of pull requests.
>>>>>>> Social Coding isn't just a slogan they use, I've seen it in
>>>>>>> action and I'm a believer.  /me steps out of pulpit.
>>>>>>
>>>>>> Don't get me wrong, I love github. In fact, I use it over Chora
>>>>>> for my daily needs. I just don't think that the lack of commit
>>>>>> history for every active branch on the front page is reason enough
>>>>>> to take the drastic step of reorganizing our branching model.
>>>>>>
>>>>>>
>>>>>>> One other thing: we can tell Github what our "default" branch is.
>>>>>>> If that branch is not "master" then we can change it so the
>>>>>>> landing page for Horde shows better activity.  Perhaps that is a
>>>>>>> middle ground here.
>>>>>>
>>>>>> Perhaps, but it's not a solution that can work with our current
>>>>>> branch structure. Each application/library has it's own x.1
>>>>>> development branch, no since one could really be seen as a good
>>>>>> candidate for a default branch to show.
>>>>>
>>>>> Looking at current Github dashboard page made me finally realise
>>>>> that splitting every application and every library into separate
>>>>> repositories is a way to go (the opposite I thought a year ago). It
>>>>> is starting to be confusing to see all those branches and thousands
>>>>> of tags in one repository even though I need only couple of
>>>>> libraries and two application from it.
>>>>
>>>> I feel very much the same. A year ago I was still in favor of a
>>>> single repository to easier test and commit changes across different
>>>> packages. The more important CI and distribution techniques like
>>>> Composer become, the more I see the disadvantages of that model,
>>>> like Gunnar outlined them already long ago.
>>>
>>> I totally agree with the *concept*. However, in practice I fear that
>>> this will be a nightmare to develop against and manage. Especially for
>>> these new developers we want to attract. I'd want to see this setup
>>> separate from our existing repository and be able to work with it for
>>> a bit before we agree to move to it completely.
>>>
>>
>> I would argue that the current situation is pretty unmanageable for  
>> new developers.  Each time I come back to the project I have to  
>> re-learn the tools like install_dev and horde_components, neither  
>> of which work out of the box.  What I'm saying is that we already  
>> need scripts to manage the developer environment.  These scripts  
>> could be reengineered to support multiple repositories, where  
>> perhaps you check out a "horde_dev" repo first that contains just  
>> enough to bootstrap a dev environment and then check out all the  
>> other Git repositories.
>
> I'm not saying that are current situation is easy as pie, but  
> install_dev only requires editing one/two lines in the provided  
> config file for it to work.
>
> Regarding splitting the repo; Sure scripts can help with our  
> workflow, but what I'm mostly concerned about is managing the many  
> dependencies that each library may have. Currently, if a new  
> developer checks out the horde repo, he/she has everything that is  
> needed (and admittedly more than they might need). If they are split  
> up, how would these dependencies be obvious, or better yet,  
> automatically communicated to the developer? It would be a daunting  
> task to read each of the framework package's xml files to determine  
> what other packages need to be installed to get that one package  
> they checked out working. It's possible that our Component scripts  
> might already provide some of what we need to do this, and if that's  
> the case then, great, let's do it. Otherwise, we need a solution to  
> this before we can split.
>
>> For what it's worth, I'm strongly in favor of splitting up the  
>> megalithic Horde repository into one-per-app/one-per-library.
>
> Last time we talked about this I was absolutely against this, mostly  
> because of problems/concerns involved with the way we were trying to  
> use git's submodules. I'm ok with splitting them now, assuming they  
> are kept totally separate and we have the scripts developed to ease  
> tasks like, e.g, switching branches of all packages in one go, and  
> for helping to manage the resolving/checking out of dependencies.

We probably need to revisit  
http://log.pardus.de/2012/08/modular-git-with-git-subtree.html
-- 
Jan Schneider
The Horde Project
http://www.horde.org/