[Zope-dev] Zope 4 release management

[Tres Seaver]

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

On 11/17/2011 01:01 PM, Martin Aspeli wrote:
> On 17 November 2011 16:32, Tres Seaver <tseaver at palladion.com> wrote:

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


That is what the ZTK does now:  it is an amalgamation of releases of
separately-managed packages, which periodically gets a versioned release
itself, mapped as an index or a 'versions.cfg' file.


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


Again, this is a choice to be made by the foundation:  any polling will
be done by the members of the foundation (this might be the biggest
non-election item on the agenda for the next annual meeting).


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


github's biggest wins, compared to self-hosted git or SVN, are for
"casual" contributors submitting easy-to-merge patches.  Given that the
new-old Zope is explicitly avoiding marketing itself to new developers, I
don't find that win all that convincing:  there is no point in having
machinery for pull requests from folks who could push the changes themselves.


> 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 think "what everybody else is doing" is all that relevant:  this
isn't a popularity contest, and Zope has permanently lost its standing
with the shiny-obsessed "cool kids."  We need to choose on the basis of
enabling the currently active developers to work together productively.


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



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/

iEYEARECAAYFAk7FZGQACgkQ+gerLs4ltQ7JBwCeNfwV5YpDX1kj5LOLoojl9RDu
guQAnRxA77PShUIQl4GmEGP4naM+Abzf
=C/n7
-----END PGP SIGNATURE-----