Late chime-in below:

On 11/17/11 2:45 PM, Tres Seaver wrote:
Hash: SHA1

On 11/17/2011 01:01 PM, Martin Aspeli wrote:
On 17 November 2011 16:32, Tres Seaver<tsea...@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

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.

-1, I feel it's at least somewhat relevant for the Zope community to occasionally examine its environment, if for no other reason than to see how it can benefit from what others are doing.

I was just thinking the other day how I'd really like to do some zc.buildout dev/maintenance (motivated in part by Ross Patterson's recent work) and immediately thought "I hope they move everything to github". And I'm delighted to see that this discussion has actually begun.

Bottom line: Zope stands to benefit greatly if the current active developers keep an open mind about how/where/when development of Zope software should occur. There are plenty of people that still think Zope software is cool, and plenty of skilled developers on github that could potentially help move it forward.


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 Seaver          +1 540-429-0999          tsea...@palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
  https://mail.zope.org/mailman/listinfo/zope )

Alex Clark ยท http://pythonpackages.com

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope )

Reply via email to