[ZF] Thoughts about the process

[Philipp von Weitershausen]

On 27 Aug 2007, at 22:05 , Chris McDonough wrote:
> FWIW, I think that a good percentage of what we're trying to  
> accomplish with a development process would be inherently taken  
> care of if:
>
> - each package that made it into whatever we call "Zope" was an  
> independently packaged
>   and release-managed entity that listed its dependencies properly  
> (probably using setuptools
>   'requires', 'extras_require", and 'tests_require' dependency  
> declarations in a setup.py
>   developed specifically for the package).
>
> - There was a document describing what is expected of a "zope"  
> package (it has its own
>   setup.py, it lists its dependencies properly, it is released with  
> "real" version numbers,
>   it's registered in the cheeseshop.. or whatever).

Precisely that is what I've been trying to accomplish with my "Guide  
for maintaining software in the Zope repository" [1].

> From what I can tell, we're getting there with this sort of thing  
> (at least I see folks working on setuptools distributions of core  
> components).  I haven't been paying much attention to how Zope 3 is  
> released lately, but the last time I looked, it was in the form of  
> a big tarball.  It would be great if instead it was released as a  
> metapackage that caused all distributions it depended on to be  
> installed when it was.
>
> At that point, we'd have a basis for argument about which packages  
> were important/good/useful enough to be depended on by the  
> metapackage (which would form the "core"), but it wouldn't be all  
> that big of a deal if something was in the core or it wasn't  
> because "well-behaved" Zope packages could be installed via  
> setuptools as required.  Additionally, things that are currently in  
> the core but don't really deserve "package" status (if only because  
> no one would be willing to step up to do the release maintenance on  
> them) could be shed.

You're right that eggs alleviate the problem of a "core" definition  
somewhat. I still think it quite necessary to define "working sets",  
in other words, a definition of packages and their versions that are  
known to work well together. We can't expect every Zope developer to  
figure this out by him/herself. I'm not saying there has to be *one*  
working set definition. The working sets should just be community- 
managed, be version-controlled and be treated as releases when it  
comes to "blessing" them for the rest of the world.


To summarize, I agree with you that ensuring a common process for the  
individual packages does most of the trick. This is what my guide is  
aiming to do. Apart from that, we need to figure out the working set  
bit. I think a technical discussion is needed here (not appropriate  
for this list).



[1] http://mail.zope.org/pipermail/zope3-dev/2007-August/023379.html