[Zope-dev] Zope 4 release management

[Martin Aspeli]

Hi,

On 17 November 2011 12:25, Laurence Rowe <l at lrowe.co.uk> wrote:
> Along with David Glick, I would like to volunteer for the Zope 4
> release management role, where I would take responsibility for
> producing the initial release of Zope 4 and David would then take over
> for the maintenance releases.

w00t :-)

+1 from me

> In doing so, I thought it would be helpful to set out our
> understanding of the mission of Zope 4. If accepted I'll work to
> produce a first draft of a roadmap based on the outcome of the recent
> sprints and discussions on this mailing list.
>
>
> Mission
> -------
>
> Zope 4 will be the first of several releases that seek to simplify our
> software stack. Over the years Zope 2 grew through the adoption of new
> technologies, notably Zope 3, but rarely removed older ways of doing
> things. Below, 'Zope 4' refers to the series of releases including
> Zope 5, 6, etc.
>
> Over the series of releases, Zope 4 will progressively remove more and
> more software as we transition to using software components shared
> with other Python web frameworks.
>
> It is as important to state what Zope 4 *is not* as what it should be:
>
> * Zope 4 will not seek to be of interest to those developing new
> applications. They should instead look to projects such as Pyramid
> that build on the experience and technologies of Zope without regard
> for the backwards compatibility concerns that will constrain Zope 4.
>
> * Zope 4 will not seek to innovate in itself but encourage innovation
> in software components shared with the wider Python web community.
>
> * Zope 4 will not move so quickly that it becomes impossible to make
> Plone, its main consumer, work with it.
>
> * But neither will Zope 4 seek to retain backwards compatibility at
> any cost. As the basis of Plone 4, Zope 2.13 will see maintenance
> releases as long as Plone 4 is supported.
>
> * Zope 4 will not have a release cycle independent of Plone. Zope 4
> only exists as a transitional path for Zope 2 based applications and
> experience has shown that Zope 2 releases not used in any Plone
> release do not receive the same level of ongoing maintenance.

I think these are sensible principles, but we shouldn't disregard the
Zope community outside Plone. Hence, if Zenoss, Silva, ERP5 and others
are willing to contribute and maintain code, they should not feel
shunted out of the development process.

That's not to say we should succumb to indefinite maintenance of all
components on the odd chance iet may be needed by "someone" (we'll
have a stable Zope 2 branch for that), but I believe we're stronger as
a bigger community with more voices than as a narrow group with only
one goal.

> Development Process
> -------------------
>
> We want to encourage all features to be developed on separate feature
> branches so we can maintain a stable trunk. Before these feature
> branches are merged they should be posted to the mailing list for
> review.
>
> This process will  necessitate a lot of merging, so I want to propose
> that we move to Git for development (something we found very helpful
> at our recent San Francisco Zope 4 sprint.) I don't have any opinion
> on where the canonical repository should be hosted - I know some
> people have strong opinions that this should be on Zope Foundation
> controlled hardware. If that's to be the case then we will need the
> svn.zope.org maintainers to setup a shared git repository on that
> machine. I think mirroring to github (and/or launchpad in future) will
> be the simplest way to provide an anonymously accessible and web
> browsable copy.

+1 - GitHub is really useful.

Martin