[dev] Horde 5?

[Vilius Šumskas]

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

Usually it is a clone of the Horde repo + in-house branches. It has a hook to autopush changes every night to the installation repository.

I do extraction from my Horde repo to my local clients' repo and later "git cherry-pick" changes to in-house branch too. This way I have a bugfix on both repositories and can push back/contribute to both Horde and my client.

> 
> > 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
> 
> 
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org