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

[Ben Klang]

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.

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