[dev] Horde 5?
Gunnar Wrobel
wrobel at horde.org
Wed Feb 29 09:04:13 UTC 2012
Zitat von Vilius Šumskas <vilius at lnk.lt>:
> Gunnar Wrobel <wrobel at horde.org> rašė:
>
>> Zitat von Vilius ?umskas <vilius at lnk.lt>:
>>
>>> Sveiki,
>>>
>>> Tuesday, February 28, 2012, 10:32:02 PM, you wrote:
>>>
>>>
>>>> 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.
>>>
>>> Yes, I miss path in the commit email too. However I feel like it could
>>> be reparsed from the email itself back to the subject with the right
>>> piece of code.
>>
>> Yes, it could. I think Michael S. once started on that but it was
>> something that probably didn't have enough of a priority to be
>> further pursued.
>>
>>>
>>> Pulling and testing is not really important to me, because I'm not
>>> core developer (see below).
>>>
>>>> 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.
>>>
>>> I completely agree with everything you say here, however I was
>>> talking about package manager (say "components") for development
>>> environment. IMHO making development environment harder to set just
>>> pushes other possible contributor away from Horde, just as much
>>> as difficult
>>> APIs or unreadable code does. Especially when we want someone to
>>> reuse our code.
>>
>> This shouldn't be hard at all. The development setup should take a
>> single command after cloning the git repository and only requires
>> PHP and a network connection - the latter being necessary for the
>> cloning as well.
>>
>> At the moment I think this actually works and you can run "php
>> horde/components/bin/horde-bootstrap" and get a development setup
>> in "horde/lib". I know I would still have a decent amount of work
>> to do before this successfully works with a splitted repo. But if
>> it would not be working like this then I would agree with you.
>
> Why I like Git is that you don't need all of that. You can clone a
> whole project in a matter of seconds and have full log almost
> anywhere. Do the development offline and push back to the source.
> Call it "accelerated development".
>
> For example usually I have only a laptop with me with simple
> git/editor installation on it. If the client calls me and says that
> their software is not working right and if that software is based on
> Horde usually I clone master Horde repository from github, fix the
> problem, cherry-pick and push it to my in-house clients' repository.
How is the clients repo structured? Is that a clone of the Horde repo
and do you run dev_install from it? Or is it a repository of the
installation itself? If you say "cherry-pick" - do you extract a patch
from your checkout of the Horde repo or do you do a "git cherry-pick".
> If the fix is essential and if I have time I also contribute the
> same patch to Horde.
>
> This would not work with splitted repositories as in most cases I
> don't even know which component has the bug. So I would have to
> clone my in-house repository which should be a somewhat composite
> repository of all Horde components used in my application and my own
> code. Not sure if this even can be configured. Not to mention that
> when I clone from in-house repository it is more difficult to
> contribute the same fix to Horde. At least I have to check the patch
> against original master/develop of Horde.
I think at the moment I do not yet fully understand the setup to
bridge the gap on how that would look like with a splitted repo. Can
you provide more details?
>
> That said my main occupation is not a developer and mostly I'm
> speaking from my own perpective here. So take my words with a grain
> of salt. I just want that contribution to Horde can still be done by
> simple guys like me, not only expert developers :)
Yes, absolutely and without a doubt.
Cheers,
Gunnar
>
> I'll go to sleep now.
>
>>>
>>>>> 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.
>>>
>>> Well, there are two types of developers: core Horde developers
>>> and external contributors or
>>> developers who just reuses Horde code. I think we would agree to
>>> disagree here that for that other (half?:)) it would be a pain to
>>> install and learn all bunch of tools they don't really
>>> need. As I said
>>> earlier I've always used simple master/develop setup with 100% GUI
>>> tools on top of it. This allowed me to bugfix some Horde bugs I
>>> was most concerned about and commit them easly, also keep my
>>> in-house code in sync.
>>> I don't really run tests or use components for anything
>>> other than generate
>>> package.xml. To tell the truth I don't even run PHP on one of
>>> my computers used for development, but maybe it's just me :)
>>
>> Yeah, sorry, I went to far. I agree with you here. I also don't
>> want to require using these tools in case you want to patch the
>> software in places where it does not work for your setup or where
>> you discovered a bug and are able to fix it yourself. These
>> contributions are very important and we should not make these more
>> difficult.
>>
>> I'm not certain that I see where these would get more difficult
>> with a splitted repository though. Assuming the setup procedure
>> would be 1) clone a repo 2) initialize development setup which
>> includes getting/updating the repos you need and 3) install/update
>> a developers installation within your webserver document root:
>> Where would the splitted approach yield difficulties? Only in case
>> a patch spans several components you have slighly more work because
>> you do not have to prepare one but several patches. I would assume
>> this is not the frequent case though.
>>
>> I admit that I'm not 100% certain that there will be no problems on
>> the route to that ideal - there will certainly be a few issues here
>> and there. But what I described above is something I don't consider
>> unrealistic. Even for the install and update routine of an
>> installation there is already code in our components tool.
>
>
>
> --
> Pagarbiai,
>
> Vilius Šumskas
> LNK TV IT vadovas
> mob.: +370 614 75713
> http://www.lnk.lt
>
>
> --
> 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