[dev] Horde 5?

[Vilius Šumskas]

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

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

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