[ZF] Please comment! Re: Zope Development Process

[Lennart Regebro]

Baiju M wrote:
> If we require a special feature which is not available in that 3rd-party 
> code,
> how egg is going to help here? For example, if we want a feature 'foo'
> in 'doctest', but 'doctest' will only have that feature in next release.

Then you need to get that feature into that code.
This problem is no different from anything, including features in Python 
or c-libraries. ;)

How much should be in the ZF repo and how much should be outside is 
amongst other considerations, a matter of weighing two issues:

1. If you have things close to each other, in the same repo, it's easier 
to contribute. It's also easier to avoid putting the features on the 
wrong level. For example, if you are working on a blog software, that 
uses a 3rd party library, and you don't have write access to that 
library, you would typically end up adding the feature in the blog 
software instead. Less repositories make it easier to put features where 
they should be.

2. When you have write access to everything it's easy to just use trunk 
of every module and add stuff as you go along. This results in unstable 
APIs and feature sets, and when several people does this it also 
frequently means that the API becomes inconsistent.

Basically, it's a part of weighing development speed vs stability. This 
is not a big problem with a small set of developers, like for example 
CPS, where many projects use trunk of many products, because the product 
needed a particular feature and it was added to CPS Core mid-release.

I also don't think it's a problem for Zope, at least not Zope3, where we 
already have the discipline not to add features and methods totally 
hurdy-gurdy.

It may however become a problem for 3rd party modules. As long as we are 
a close-knit community getting features into 3rd party modules that are 
on separate repositories will probably not be a problem anyway.



(Besides, adapters can avoid this in a very nice way. You implement the 
feature in a "futureware" module as a IMyExtendedBla(IBla) and when the 
feature gets into the 3rd-party module proper, you just change 
IMyExtendedBla to be another name for IBla, and deprecate it. ;) )