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

Wed Mar 27 16:26:04 UTC 2013

Zitat von Ben Klang <bklang at horde.org>:

> On Mar 27, 2013, at 11:42 AM, Michael J Rubinsky <mrubinsk at horde.org> wrote:
>
>>
>> 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.
>>
>
> The best way I know how to answer this is to compare it to how the  
> Ruby community has solved this issue.  By taking advantage of the  
> packaging information available in each repository, those  
> dependencies can be downloaded automatically.  The tool is called  
> Bundler and can read from the Gemspec (which is equivalent to  
> package.xml) to determine dependencies.  It also allows for  
> dependencies to be locked to specific versions or overridden with a  
> Gemfile (for which I do not think an equivalent exists in PHP).  We  
> would have to improve our horde_components scripts to parse the  
> package.xml files and understand how to fetch development versions  
> of packages when requested.  I'm not saying it's trivial work to  
> solve this, but thanks to our new PEAR infrastructure it should be  
> much simpler than it has been in the past.

That's what Composer is for in the PHP world.

> And what you gain for it is a beautiful experience for the  
> developer: he simply clones the repository on which he wants to  
> work, runs a single command (let's call it "horde_components  
> bundle", and is equivalent to Ruby's "bundle install"), and  
> immediately has a working development environment with only the  
> exact dependencies he needs.
>
> /BAK/
>
>>> 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.
>>
>> --
>> mike
>>
>> The Horde Project (www.horde.org)
>> mrubinsk at horde.org
>> --
>> dev mailing list
>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Jan Schneider
The Horde Project
http://www.horde.org/