[Zope-dev] Zope 4 release management

[Martin Aspeli]

On 17 November 2011 16:32, Tres Seaver <tseaver at palladion.com> wrote:

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

The innovation is in making it possible for users of Zope 2 to better
be part of the wide Python web framework community and use tools and
frameworks that are also in use in frameworks like Pylons/Pyramid,
Django and TurboGears. The other innovation is in making our platform
leaner, more maintainable and easier to understand and debug.

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


+1

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

+1

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

-1 - we'll need something to amalgamate this into a release and we'll
need a way to manage and number those releases.

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

In the Plone community, we held a poll. GitHub won hands-down. The
second choice was staying with self-hosted SVN

GitHub is a big leap forward in software project support. It's also
rapidly becoming a de-facto place for many people to look for
software. We win if the people we want to encourage to fix bugs or
contribute features have a low barrier to entry.

Note that this also includes Plone developers working on Plone at this
stage, since Plone has now moved to GitHub. So, my personal vote would
be for Zope to use GitHub (with a backup mirror), allowing me to have
a more integrated toolchain.

Personally, I find GitHub substantially better than BitBucket,
especially for collaboration, and Launchpad nearly unusable. I'd
encourage you to look at usage and growth statistics for the three
main hosting/collaboration services.

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

Right - Plone has chosen to stick with self-hosted Trac for bug
tracking. I'd imagine Lanchpad remaining Zope's bug tracker.

Martin