[dev] Horde 5?

Tue Feb 28 22:40:22 UTC 2012

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.

>
>>> 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.

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