[Zope-dev] Zope 4 release management

Tres Seaver tseaver at palladion.com
Thu Nov 17 16:32:06 UTC 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/17/2011 07:25 AM, Laurence Rowe 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.
> 
> 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.


I smell something funny in here:  if we aren't innovating, why are we
making the effort?


> * Zope 4 will not move so quickly that it becomes impossible to make 
> Plone, its main consumer, work with it.


We should be working to enable the other Zope2-consuming projects to keep
up, too.


> * 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.


As long as any significant body of developers commits to maintaining it,
even if the Plone devs don't care any more.


> * 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 would actually argue that "Zope4" have no real release cycle at all:
instead, the individual pieces which make up Zope should have their own
cycles, with perhaps a ZTK-like tracking set that Plone and others use as
platform targets.


> 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.)


Note that this question is *not* suitable for "loudest voice on zope-dev
wins" ressolution.  The software belongs to the Zope Foundation, which
will make any such decision.  The work done on github by the Zope4
sprinters in SF  should be seen as scratchpads for work which will be
migrated back into the canonical repository for each project.

A couple of points for consideration:

- - bzr and hg are pretty much isomorphic to git WRT this kind of practice.
  Both have claims on our community which Git does not (hg because it is
  the tool of choice for Python, bzr because we already use Launchpad).
  Note that I use Git daily, and the others somewhat less frequently:  I'm
  not speaking from ignorance here.

- - Merging feature branches in SVN is not *that* difficult, typically:  I've
  done scores of such merges myself with almost no pain (and the really
  painful ones would have been pretty much as bad with git / bzr / hg).


> 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.


I would note that hosting Git repositories without Github reduces the
value proposition substantially:  Git's wins in merging are much less
significant than the collaboration workflow changes which github makes
possible (tracking pull requests, in particular).  Launchpad provides a
similar mechanism, albeit one which is less sexy to use.  OTOH, github's
bug tracker is nothing to write home about, compared to Launchpad.


< 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.


Note that we already have the SVN repos for many projects mirrored to
Launchpad[1], as well as having our bug trackers there[2].

[1] https://code.launchpad.net/zope

[2] https://bugs.launchpad.net/zope



Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7FNwYACgkQ+gerLs4ltQ5IawCfU1AHBIcwg7vCCGq32BHKUyUh
amIAn14xfGE1dggzHKgK3CccmUtAgcx0
=OHOC
-----END PGP SIGNATURE-----



More information about the Zope-Dev mailing list