[dev] Horde 5?

[Vilius Šumskas]

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.

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.

>> 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 :)

-- 
Best regards,
 Vilius