[dev] Horde 5?

[Gunnar Wrobel]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Gunnar Wrobel <wrobel at horde.org>:
>
>>> None of the arguments I've heard yet for splitting the repository  
>>> are very convincing to me, including the argument of having a  
>>> split repository making it more attrative for developers. As  
>>> Vilius said, there is a difference between a developer using our  
>>> component in one of his (non-horde) projects and a developer that  
>>> is actively developing the horde component and  
>>> submitting/commiting changes to that component. The former *can*  
>>> use only the components they want - via PEAR - and all the  
>>> dependencies are taken care of.
>>
>> That depends on what the external developer is trying to do.
>>
>> I think I already provided that example before: If I combine my  
>> brief experience with the z-push code that I had quite a while back  
>> with how I judge your coding style then I conclude that the  
>> Horde_ActiveSync library you wrote is far more attractive for other  
>> projects to extend than relying on z-push.
>
> Thanks, that is certainly the hope :)
>
>> At least assuming that Horde_ActiveSync gains the final few  
>> features that it still lacks in comparison to the z-push code. But  
>> chances for this are high.
>>
>> At the moment there is of course no other project using  
>> Horde_ActiveSync. I'm not going to pretend that this will happen  
>> once we split our repo :) The most important point would be  
>> documenting the library and explaining where the extension points  
>> are.
>>
>> But a splitted repo would help as well. I don't expect that any  
>> non-Horde project trying to adopt that package could do so right  
>> away. It is not so uncommon that you find minor problems and flaws  
>> with a library that has not yet been used by many people outside of  
>> the original context. In that case you definitely want a git  
>> checkout and not some PEAR package to rely on.
>
> This, I think is the core of our disagreement. I believe any  
> external developer should be using the PEAR packages unless they are  
> actively helping us develop the library. After all, that's why we  
> publish the libraries individually, so others can use them without  
> the baggage of a full Horde stack. *Especially* if they are being  
> consumed by non-Horde coders, where you would want the most stable  
> code. I don't buy the argument that consumers of a newly released  
> package should still be using a Git checkout of that package in  
> place of a release because a new package might have bugs to work  
> out. Any package, regardless of age, will have bugs though I agree a  
> newer package may have *more* bugs. Another benefit of distributing  
> our libraries as individual PEAR pacakges is that we are able to  
> respond to and release bug fixes very quickly now, without having to  
> coordinate the release with the rest of the framework. So, IMO,  
> there is no disadvantage to using the PEAR package in this context.  
> In the cases where we are unable to release a fix quickly, it's  
> likely because of some larger problem with the design and is  
> unlikely to be available in Git much sooner. The only changes that  
> sit in Git and do not make it to releases quickly are usually BC  
> breaking changes, and those probably shouldn't be used externally  
> until they are released anyway. Git code will always be less stable  
> and more likely to be broken compared to a release - regardless of  
> the age of the package.

The point is not *using* the package for development. I'm fine with  
people using a stable release for their own development work. That  
makes sense and is what you should do when you start with external  
libraries.

The point I'm trying to make is about crossing the border from *using*  
the code to *contributing* to the code. While you can patch a PEAR  
package you should not. This is released code and outside of the  
development context. Files could have been modified by PEAR tasks  
during the installations and the file paths obviously will change  
during the installation. And of course you lack "git diff" and other  
stuff once you start modifying the library.

Without having had a closer look into composer - the way I understand  
their model it works as follows:

You start using a Horde library by declaring the PEAR dependency for  
your project:


{
     "repositories": [
         {
             "type": "pear",
             "url": "http://pear.horde.org"
         },
     ],
     "require": {
         "Horde_ActiveSync": "1.0.0"
     }
}

Once you hit a problem and need to contribute back, you would switch  
to git so that you can work in development context.

{
     "repositories": [
         {
             "type": "pear",
             "url": "http://pear.horde.org"
         },
         {
             "type": "vcs",
             "url": "git://github.com/horde/Horde_ActiveSync.git"
         }
     ],
     "require": {
         "Horde_ActiveSync": ">=1.0.0"
     }
}

Once upstream releases you can switch back.

I admit that this is only theory for me at the moment. I didn't try it  
myself yet. But the above example is what I would strive for. If it  
turns out to be far less easy than what I depicted here I would  
probably change my mind :)

>
>> I picked a single package for this example - even one that might be  
>> dear to you to try to be convincing ;) - but honestly: I think many  
>> of our packages would have that problem. We code the stuff for the  
>> Horde context. Yes, we improved tremendously since the Horde 3  
>> days. And there is actually a lot in our components that would be  
>> ripe for consumption in other projects.
>
> Well, as you state, this has improved greatly. I think we no longer  
> code just for the Horde context, other than in Core, of course.  
> Sticking with the example, I have indeed spent quite a lot of time  
> and energy abstracting things out of the ActiveSync code just for  
> this reason. It should be possible with the current code to easily  
> use it with any other datastore by "only" writing a single backend  
> driver for it...well, assuming our Rpc layer is also used, but you  
> get the idea...and I think I'm getting a little of topic here anyway  
> :)
>
>> Actually I did so myself: I did integrate several Horde 4  
>> components with the Zend 1 framework. This works just fine. But of  
>> course you loose the version control context if you do so. Which is  
>> a pity in the long run.
>>
>>> It's the latter that we are concerned about here. Sure, we can  
>>> benefit from attracting more developers that are willing to donate  
>>> time to our project, but I don't think that requiring them to  
>>> clone a monolithic repository is asking too much.
>>
>> Try to bridge Horde with Zend framework 2 and Symfony 2 in the  
>> context of a larger coding project. Pulling a monolihic repository  
>> will not be an option. Working based on PEAR will mean that no  
>> patches will be contributed back. Or at least it will be harder.
>
> I still think that external consumers should be using PEAR.  
> Otherwise, why are we publishing them? Why would a monolithic  
> repository not be an option? How would that be different from having  
> to use some custom-to-horde toolchain in order to manage the  
> multiple git repositories that would be necessary to use some of our  
> components? I'm not saying you are wrong, I just don't understand  
> the reasoning here. Either way, there would have to be some magic  
> involved on the external developer's side.
>
>>> ..and might even lead to them wanting to contribute to more  
>>> components than the original one.
>>>
>>> I think it would be more work to ask them to figure out the needed  
>>> dependencies any single compononet would require and  
>>> download/install each of those. Sure, we could put the energy/time  
>>> into leveraging existing tools or implementing new tools to make  
>>> this somewhat easier for other developers looking to contribute to  
>>> Horde, but why? At some point I would think it would just become  
>>> easier to:
>>>
>>> git clone horde
>>> horde/framework/bin/install_dev
>>>
>>> in order to get everything...and who knows, they might even  
>>> discover components they were not aware of because they now have  
>>> the full checkout.
>>>
>>> Will we discourage some casual developers that might be interested  
>>> in contributing? I don't think so...the libraries are solid, well  
>>> thought out code - arguably the best in our core areas. That is  
>>> what should attract developers, not the repository structure.
>>
>> The fact that the code is there and structurally sound is probably  
>> not enough to attract more devs. The repository structure is also  
>> insignificant. The main factor is documentation and publishing how  
>> to use the components.
>
> Totally agree. I was simply stating that repository structure is not  
> going to make or break somebody's decision to use Horde.
>
>> I know I write way too much text in this thread for the fact that I  
>> don't see the repo structure as one of the major issues at the  
>> moment. It would help more if I'd write docs instead :) But I'm on  
>> the other hand happy that we are having this discussion as all  
>> because this has been rejected outright before.
>
>> And I'm still convinced it makes sense to split at some later point  
>> in time simply because I failed integration Horde code with other  
>> components outside of Horde context. Which does not make me happy :)
>
> I'm still currently against this, but am keeping an open mind. You  
> do make good points, I just don't feel they justify taking such a  
> radical step as splitting our repository. I'll obviously adapt to  
> whatever the majority viewpoint ends up being. :)
>
>
> -- 
> mike
>
> The Horde Project (www.horde.org)
> mrubinsk at 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