[dev] Horde 5?
Gunnar Wrobel
wrobel at horde.org
Tue Feb 28 20:32:02 UTC 2012
Zitat von Vilius ?umskas <vilius at lnk.lt>:
> Hi,
>
> Tuesday, February 28, 2012, 9:20:52 PM, you wrote:
>
>>>>> but personally me would
>>>>> be against spliting repository for every application or/and framework
>>>>> library. Usually I do only minor bug fixes, it would be a pain to
>>>>> keep 50 or more repositories up to date in development environment,
>>>>> because all Horde components are interconnected and you cannot develop
>>>>> and test if one of them is outdated.
>>>
>>>> While I, too, am somewhat opposed to splitting the repo, I have to
>>>> disagree with some of your reasoning. We are striving to make our
>>>> components atomic. In fact, most of our framework libraries ARE
>>>> actually usable as stand-alone components, and do not require a
>>>> traditional horde install to work. That is one of the arguments for
>>>> splitting the framework libraries - to make them appear more atomic
>>>> and to relieve a developer from the chore of having to install the
>>>> whole horde stack if he/she wants to help develop the code for a
>>>> single library.
>>>
>>> Yes, most of the libraries doesn't require a whole horde install, but
>>> still they need other libraries usually. At least Horde_Autoloader,
>>> Horde_Exception, Horde_Translation and a few others. I don't see how
>>> splitting the repository would help here. Quite the opposite. Let's
>>> say I want to work on Horde_View. For splitted repository I would have
>>> to actually know the dependency list and grab repositories one by one
>>> for 5-7 libraries.
>>>
>>> Or let's say I would want to work on a new Horde application.
>>> Again, I would have
>>> to actually know all the features I want to implement in new
>>> application in advance, clone all needed libraries one by one, and
>>> update them later during development.
>>>
>>> At least for me cloning one repository is a lot easier. Especially
>>> when git is so great with big repositories and considering speed of
>>> the internet nowaways.
>
>> This is a question of having the right tools for the job. Given the
>> toolset we currently use you are of course right. That wouldn't make
>> any sense and is way to cumbersome.
>
>> But other PHP frameworks are doing exactly the same thing: they start
>> to split their software into components. This makes reuse a lot
>> easier. Developers can choose the best parts from the frameworks they
>> like. And having clearly delineated interfaces between your modules
>> help the development in general.
>
>> One of the results from Symfony 2 is the "composer" tool: It is
>> specifically designed for this "many-git-repositories" situation. They
>> try to use it as package manager in general and I'm still skeptical if
>> that will really work out. But for the development situation it may
>> actually help.
>
> Even with improved toolset and as a developer I don't buy this.
> Library dependencies and repository structure are two different things
> for me. Having one big repository doesn't prevent you from choosing
> "best parts from the framework".
It does not prevent it but it makes it more difficult. With a "repo
per component" strategy you can follow exactly the code you are
interested in via the commit stream and will not need to try to
isolate the interesting bits from the noise of the whole batch of
components you are not interested in. This is something I still miss
from the CVS days where the commit mail immediately told me if I want
to take a close look or if it is just something I'll peek into if I
have the time. Pull requests also go to exactly one component, testing
runs with just this one component, and in the end all components are
treated somewhat equally - it does not matter wether the path starts
with "framework/" or not.
I definitely won't say that you can't work with a monolithic
repository. We are doing it every day and it works just fine. But
every time I hit something of the things I outlined above - I have the
feeling that is not the correct model. We already do 100 components
and these would better fit into 100 repos.
>
> I feel like emulating package manager is too much "overhead" for
> development.
No. Absolutely not. Package management is the key element and one of
the reasons why I work with Horde. It is the one central element that
I believe many, many web apps didn't get right so far. Why are
distributions successful after all? You don't install Debian from a
single tar archive and slap it onto your hard drive. The flexibility
you get from a distribution is one of the key factors that make them
attractive.
Yes, web applications are a different kind of beast. But everyone is
moving into the cloud now and all these web application are getting
more complex by the minute. I know installing Horde is not trivial -
but updating is - at least since Horde 4.0. And I consider that
extremely important. It allows us to have a fast paced development, it
allows us to push releases quickly, it allows the admins to update
immediately, to keep their systems secure. This is mandatory. There
are Horde 3 installations of large universities out there that display
"Copyright 1999-2006". Package management is what allows to update
quickly while working with an extremely complex and flexible software.
We don't care which apps you install - the update will work anyway. Of
course PEAR is a crappy package manager - but it is at least something
and I hope time will give us better tools.
> Keep in mind that not every developer uses Unix. I
> personally develop on Windows with TortoiseGUI/Editplus IDE. I
> would have to
> specifically set my tools to use "components" somehow, because in
> splitted repository "components" would become a requirement.
For every one of the core developers it is already a requirement.
PHPUnit is a requirement for any Horde developer as well. These are
PHP tools, they can be easily installed on any system that supports
PHP. Granted - we still lack decent docs that would make that easy.
But of course there are requirements to any development environment.
And if I look at how these requirements have evolved during the time I
have been PHP developer - there has been quite some changes since my
initial days. PHPUnit, PHP Code Sniffer, Pdepend, PEAR, PHP documentor
and probably other stuff I can't think of at the moment.
>
> Also having all the libraries in one repository could help market
> Horde as a platform for applications, not as a set of separate
> libraries. IMHO it is
> more important.
Horde as a platform for web applications is also more important to me
than promoting Horde as a development framework. But I don't see how a
single repo has a significant effect here.
Cheers,
Gunnar
>
>> We have our own "components" tool which is also targeting the
>> component based development and release management. I would also add
>> stuff we are missing there.
>
>> So all in all I would say we can split if there is no impediment of
>> the development process.
>
>> Which - btw - is an unlikely result if we'd try to squeeze it in
>> before Horde 5.0. So while I'd like to split I'm definitely in favor
>> of doing that during a somewhat more quiet period.
>
>> Cheers,
>
>> Gunnar
>
>>>
>>> --
>>> Best regards,
>>> Vilius
>>>
>>> --
>>> Horde developers mailing list
>>> Frequently Asked Questions: http://horde.org/faq/
>>> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>
>> --
>> Core Developer
>> The Horde Project
>
>> e: wrobel at horde.org
>> t: +49 700 6245 0000
>> w: http://www.horde.org
>
>> pgp: 9703 43BE
>> tweets: http://twitter.com/pardus_de
>> blog: http://log.pardus.de
>
>
>
>
>
> --
> Best regards,
> Vilius
>
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
--
Core Developer
The Horde Project
e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org
pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de
More information about the dev
mailing list