[Framework-Team] Re: plone products leaders (v2)

Balazs Ree ree at ree.hu
Fri Mar 23 08:52:47 UTC 2007

On Fri, 23 Mar 2007 08:53:05 +0100 Wichert Akkerman wrote:

> I'm not convinced that we have the problems that Thierry sees. I do see
> that we have an increasing complexity and inter-dependencies between
> components which will require some changes to the release process for
> Plone 3.5 and later.

I also agree that the main problem is integration. Plone has reached a 
higher level of complexity with its inter-dependencies and and it starts 
falling out of our hands more often.

Perhaps one way to improve the situation, would be to properly handle 
inter-component dependencies, also by individual component versions. (ie. 
package A requires version >= 2.5 and <=3 of package B.) This is, for 
example, done reasonably well in Debian package management, and with eggs 
we could even do it better. However this would not result in solving all 
problems at once, because we aim at the evolution of all packages at the 
same time and we can't give this up at the moment. So in many cases 
dependancy would mean "depend on svn trunk". (As an example, we even 
require the newest and often changing Zope version and even we can't fix 
that.) Hpwever I see a chance that moving on to 3.5 would result in a 
better maintainable system because some parts would stabilize by then.

It is remarkable to mention the dark side of Debian too, that as a 
consequence of aiming to build a system from stable products, they have 
an extremely lazy release cycle. This often makes stable releases 
obsolate at the time of their appearance. With an example I would say 
that if we followed this road, we'd be forced to base Plone 3.0 on Zope 
2.8 and we could think of basing 3.5 already on Zope 2.9. And of course 
we could not and we would not want to do this.

> I also do not believe in electing leaders. Democracy works reasonably in
> politics, but when you are trying to manage a product and its roadmap
> you need people with a certain set of skills and experience, not people
> who are popular or happen to have better social skills. Personally I
> think our current system based on PLIPs and a framework team to review
> them works very well.

Also another significant difference with the Debian model, is that in 
Debian a package maintainer is not really the product developer. The 
maintainer takes a (stable) release of the product from upstream, 
configures and tests it for stability. He is rarely responsible for 
coordinating the development of the product he maintains. The package 
maintainer of Debian, is more analoguos to the Plone release manager role 
than to the lead developer(s) of a given component.

Balazs Ree

More information about the Framework-Team mailing list