[Framework-Team] Re: plone products leaders (v2)
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.
More information about the Framework-Team