[dev] Horde 5?

[Michael J Rubinsky]

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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20120228/f232d2cf/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120228/f232d2cf/attachment-0003.bin>