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. * 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. 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. Laurence
Hi, On 17 November 2011 12:25, Laurence Rowe <l@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
On Thu, Nov 17, 2011 at 7:25 AM, Laurence Rowe <l@lrowe.co.uk> wrote: ... (Interesting roadmap snipped)
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.
Why on that machine? Why not have the ZF set up git.zope.org? As the primary maintainer of svn.zope.org, I'm not volunteering to have more stuff there. :)
I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy.
I haven't used GitHub myself, but I gather it's good. :) Why not just let them host the project? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On 17 November 2011 15:50, Jim Fulton <jim@zope.com> wrote:
On Thu, Nov 17, 2011 at 7:25 AM, Laurence Rowe <l@lrowe.co.uk> wrote: ... (Interesting roadmap snipped)
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.
Why on that machine? Why not have the ZF set up git.zope.org?
As the primary maintainer of svn.zope.org, I'm not volunteering to have more stuff there. :)
I think mirroring to github (and/or launchpad in future) will be the simplest way to provide an anonymously accessible and web browsable copy.
I haven't used GitHub myself, but I gather it's good. :) Why not just let them host the project?
That's the conclusion Plone came to. We have experience of running such a migration now, so can probably help. We also have some mirroring for backup happening. Martin
-----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@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-----
On 17/11/2011 16:32, Tres Seaver wrote:
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.
Small point: the software is open source and anyone who wants can maintain it anywhere they want ;-) If the energy of the people doing the current round of development is focused on Git, I say let them use Git. Provided they keep the svn markers in (and there's no reason not to!) then a git svn dcommit from someome authorized will bring all the work back to wherever the Zope Foundation wants it... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 17 November 2011 16:32, Tres Seaver <tseaver@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
-----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@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@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-----
On 17 November 2011 19:45, Tres Seaver <tseaver@palladion.com> wrote:
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).
When is the next annual meeting? Laurence
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/17/2011 03:14 PM, Laurence Rowe wrote:
On 17 November 2011 19:45, Tres Seaver <tseaver@palladion.com> wrote:
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).
When is the next annual meeting?
Q1 2012 (date still to be set by the board). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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/ iEUEARECAAYFAk7FbKcACgkQ+gerLs4ltQ6hHgCYtQIoFi+NTdakkcjiBR4bsOfN 3wCcDerWtgsaNgB/XITcL63wTQYfZus= =nyVH -----END PGP SIGNATURE-----
On 17 November 2011 20:20, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/17/2011 03:14 PM, Laurence Rowe wrote:
On 17 November 2011 19:45, Tres Seaver <tseaver@palladion.com> wrote:
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).
When is the next annual meeting?
Q1 2012 (date still to be set by the board).
Is there any possibility the board could poll the members of the Zope Foundation between annual meetings? We're not looking to migrate the whole of svn.zope.org, only use github for what is essentially a new project. Laurence
Hi, Late chime-in below: On 11/17/11 2:45 PM, Tres Seaver wrote:
-----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@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.
-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. Alex
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@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-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Alex Clark · http://pythonpackages.com
On Feb 1, 2012, at 00:05 , Alex Clark wrote:
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.
This discussion seems to unnecessarily combine at least two distinct issues: - what RCS software to use - where to host it It may be easier if we disentangled them. Speaking purely as a developer, I'm leaning to Git when it comes to the RCS software decision between Subversion and Git. But I can use both equally well. Where it is hosted, well, purely as a developer it doesn't matter to me, unless I need to give up too much personal data to get access. From the perspective as a Zope Foundation member the RCS software decision is a technical detail that doesn't matter much. I'm more concerned with the "where" question, though. The Zope Foundation is tasked with safeguarding the software released under the Zope Foundation umbrella, and it is tasked with enforcing the contributor agreements everyone signed. Commits can only be made by signed contributors, and contributors are specifically disallowed to take outside code they don't own and commit it to the repository. We already have the technical infrastructure in place for most of this, such as ZF-controlled logins on svn.zope.org, access only via SSH key, etc. Our current "where" can be fully trusted, so to speak, and the people tasked with maintaining this infrastructure are known, accountable, and part of the foundation. My third role is secretary of the Zope Foundation Board of Directors and in that role I collect and maintain contributor applications and the (private) data associated with it. I can vouch that our current means of storing this data is reasonably secure. I can't make that assertion if the data is stored somewhere out of Zope Foundation control. My last role is admin for the ZF infrastructure and servers. In that role I would be involved in executing any changes in repository hosting. If only the RCS software changes that's a chunk of work, but doable. Git service can be added to the ZF infrastructure and packages can be migrated into Git repositories, probably on a "as-needed" basis. Most of the current authentication and safety infrastructure could stay in place. On balance and taking all my roles into account, sticking with SVN and the current hosting is the most attractive option. Moving to Git in the current hosting environment is doable, it means work, but I feel I've done my job keeping the software, access to it, and contributor data as secure as possible. Any option that involves moving to a different host altogether not only makes me feel I haven't done my job, it may also throw up legal questions. jens
On 2/1/12 6:08 AM, Jens Vagelpohl wrote:
On Feb 1, 2012, at 00:05 , Alex Clark wrote:
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.
This discussion seems to unnecessarily combine at least two distinct issues:
- what RCS software to use - where to host it
It may be easier if we disentangled them.
Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle.
Speaking purely as a developer, I'm leaning to Git when it comes to the RCS software decision between Subversion and Git. But I can use both equally well. Where it is hosted, well, purely as a developer it doesn't matter to me, unless I need to give up too much personal data to get access.
From the perspective as a Zope Foundation member the RCS software decision is a technical detail that doesn't matter much. I'm more concerned with the "where" question, though. The Zope Foundation is tasked with safeguarding the software released under the Zope Foundation umbrella, and it is tasked with enforcing the contributor agreements everyone signed. Commits can only be made by signed contributors, and contributors are specifically disallowed to take outside code they don't own and commit it to the repository. We already have the technical infrastructure in place for most of this, such as ZF-controlled logins on svn.zope.org, access only via SSH key, etc. Our current "where" can be fully trusted, so to speak, and the people tasked with maintaining this infrastructure are known, accountable, and part of the foundation.
My third role is secretary of the Zope Foundation Board of Directors and in that role I collect and maintain contributor applications and the (private) data associated with it. I can vouch that our current means of storing this data is reasonably secure. I can't make that assertion if the data is stored somewhere out of Zope Foundation control.
My last role is admin for the ZF infrastructure and servers. In that role I would be involved in executing any changes in repository hosting. If only the RCS software changes that's a chunk of work, but doable. Git service can be added to the ZF infrastructure and packages can be migrated into Git repositories, probably on a "as-needed" basis. Most of the current authentication and safety infrastructure could stay in place.
On balance and taking all my roles into account, sticking with SVN and the current hosting is the most attractive option. Moving to Git in the current hosting environment is doable, it means work, but I feel I've done my job keeping the software, access to it, and contributor data as secure as possible. Any option that involves moving to a different host altogether not only makes me feel I haven't done my job, it may also throw up legal questions.
Fair enough, all of this sounds reasonable. My only point was that it should be someone's role in the ZF to take a look around at the available options in today's software development ecosystem. If github.com is attractive to you, great. If it's not and you are happy with the status quo, also fine. But like anything else, there are pros and cons associated with either approach. E.g. Plone's move to github has been a challenge for a lot of people, and we continue to struggle with it everyday; but I know it was the right move for the software and the project so I feel good about what we are doing. Alex
jens
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Alex Clark · http://pythonpackages.com
On Wed, Feb 1, 2012 at 13:03, Alex Clark <aclark@aclark.net> wrote:
- what RCS software to use - where to host it
It may be easier if we disentangled them.
Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle.
It is entangled, but it is important to notice that they are separate concerns. I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows. But where to host it is a tricky issue. Ownership and control is one big argument for having our own servers. Githubs forking/merging process a big argument for going to github. Should you then decide that github is the place to host it, well, then git is the software to use. To be honest I see little point in just setting up our own git repository. Yeah, maybe git is better from some technical standpoints, but it's also harder to use, and the question then becomes just religion. What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuuuuuut... it costs $250 per commiter and year, so that's not an option, obviously.) //Lennart
On 2/1/12 8:21 AM, Lennart Regebro wrote:
On Wed, Feb 1, 2012 at 13:03, Alex Clark<aclark@aclark.net> wrote:
- what RCS software to use - where to host it
It may be easier if we disentangled them.
Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle.
It is entangled, but it is important to notice that they are separate concerns.
I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows.
But where to host it is a tricky issue. Ownership and control is one big argument for having our own servers. Githubs forking/merging process a big argument for going to github. Should you then decide that github is the place to host it, well, then git is the software to use.
Actually, they introduced improved Subversion client support late last year: - https://github.com/blog/966-improved-subversion-client-support (they've supported import-from-svn and limited svn client support for longer)
To be honest I see little point in just setting up our own git repository. Yeah, maybe git is better from some technical standpoints, but it's also harder to use, and the question then becomes just religion.
What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuuuuuut... it costs $250 per commiter and year, so that's not an option, obviously.)
//Lennart _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Alex Clark · http://pythonpackages.com
On 02/01/2012 02:29 PM, Alex Clark wrote:
Actually, they introduced improved Subversion client support late last year:
- https://github.com/blog/966-improved-subversion-client-support
Unfortunately it is too unstable to be usable. Wichert.
On Wed, Feb 1, 2012 at 14:29, Alex Clark <aclark@aclark.net> wrote:
On 2/1/12 8:21 AM, Lennart Regebro wrote:
Should you then decide that github is the place to host it, well, then git is the software to use.
Actually, they introduced improved Subversion client support late last year:
- https://github.com/blog/966-improved-subversion-client-support
And now you have two problems. :-) //Lennart
On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote:
What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuuuuuut... it costs $250 per commiter and year, so that's not an option, obviously.)
Just to be sure I keep the fire on: what about self-hosted Gitorious? It's not as neat as Github, but you still have the same (similar) forking/merging abilities than Github. Jonathan
On 1 February 2012 14:35, Jonathan Ballet <jon@multani.info> wrote:
On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote:
What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuuuuuut... it costs $250 per commiter and year, so that's not an option, obviously.)
Just to be sure I keep the fire on: what about self-hosted Gitorious? It's not as neat as Github, but you still have the same (similar) forking/merging abilities than Github.
From me, the key advantage of Github is the functionality to easily discuss code in pull requests and the one-click merging where appropriate. It takes me much less effort to respond to a Github pull request where I have all the relevant information to hand than an email with a patch or a request to take a look at a branch in subversion. For projects I work on in my own time that often makes the difference when it comes to responding in a timely manner.
Github certainly has it's problems too, but it has an api for scripting which makes it possible to send better commit emails or integrate with Launchpad for bug tracking if someone wants to put the effort in. I don't really have an opinion on whether Github or a repository hosted on a zope.org server is nominated as the ZF's canonical repository (presumably with a pre-receive hook that checks all commit authors are known to have signed the contributor agreement.) With DVCS it shouldn't really matter. It's access to improved tools that's important for me. Laurence
Le 01/02/2012 14:21, Lennart Regebro a écrit :
I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows.
Disclaimer : Though I use zope libs every day, I'm not a comitter nor member of foundation. I'm a bit amazed by this argumentation. I think one important thing is that subversion is centralized while dvcs are not. With dvcs everyone got full history of zope libs. I personally find it a big pro for a free software. More over with dvcs someone may fork a product on his side (a branch of his own, not on a zope server) and make it evolve, still having ability to merge updates (and auto merge in dvcs are superior to the one found in subversion). All I see here is usability not religion ;-) Now about github, I may say that gitorious.org exists and is free-software and gitosis + gitweb are on most linux distribs and offers same features as today's zope svn. I think the same can be said for hg. But really github/bitbucket is just hosting, it's not like subversion, you got all your data and history at home also, so you can leave github as soon as you want (if you do not use other features). Finally, moving a subversion repo to git is really easy (and I think it's the same with hg) Hope this helps. Alex -- Alexandre Garel 06 78 33 15 37
Am 01.02.2012, 15:40 Uhr, schrieb Alexandre Garel <alex.garel@tarentis.com>:
All I see here is usability not religion
Which is pretty much what Jens said originally. To me, much of the argument seems to be trying to solve a different problem: getting more people involved in contributing to Zope or at least maintaining important packages. While this is a laudable goal I think it is has little to do with the tools involved, something that is becomingly increasingly irrelevant as more and more third-party packages are used in Zope projects; something which Zope did a great deal to encourage. Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. On hosting: personally, it does matter to me a great deal where the little code I write is hosted. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Feb 1, 2012, at 15:53 , Charlie Clark wrote:
Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping.
For any code released under the Zope Foundation umbrella that hurdle cannot be removed, anyway. To be frank, I don't even think that's a hurdle. And it helps to remind the signer that there are legal requirements and responsibilities involved. jens
On Wed, 2012-02-01 at 16:29 +0100, Jens Vagelpohl wrote:
On Feb 1, 2012, at 15:53 , Charlie Clark wrote:
Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping.
For any code released under the Zope Foundation umbrella that hurdle cannot be removed, anyway.
To be frank, I don't even think that's a hurdle. And it helps to remind the signer that there are legal requirements and responsibilities involved.
For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks "sign" the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines. I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand). - C
Hi Chris,
For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks "sign" the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines.
I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand).
Yes, I remember "signing" the Repoze repository agreement in a similar way a few years ago. I liked it because it was convenient, sure. But as you say, I doubt it would hold up in a court. Speaking of those paper contributor agreement availability, you'd be surprised. I have them all in 3 large binders, for every signer the latest agreement they signed. jens
On Thu, 2012-02-02 at 08:46 +0100, Jens Vagelpohl wrote:
Hi Chris,
For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks "sign" the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines.
I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand).
Yes, I remember "signing" the Repoze repository agreement in a similar way a few years ago. I liked it because it was convenient, sure. But as you say, I doubt it would hold up in a court.
IMO, neither would be likely to withstand an extremely well-funded court challenge, because a well-funded legal team could probably convince a judge to disallow distribution of the code for long enough that it would effectively kill the project anyway. - C
On Wed, Feb 1, 2012 at 15:40, Alexandre Garel <alex.garel@tarentis.com> wrote:
I'm a bit amazed by this argumentation. I think one important thing is that subversion is centralized while dvcs are not.
And I think it's very unimportant.
With dvcs everyone got full history of zope libs. I personally find it a big pro for a free software.
You get that with svn too.
More over with dvcs someone may fork a product on his side (a branch of his own, not on a zope server) and make it evolve, still having ability to merge updates (and auto merge in dvcs are superior to the one found in subversion).
You can do that with svn too. The merging of it is easier with something like github or gitorious, but git in itself doesn't really help. //Lennart
Hi, The ZF notes from May mentioned a VCS discussion. Is this the the latest thread or did I miss one more current for some reason? On Wed, Feb 1, 2012 at 3:40 PM, Alexandre Garel <alex.garel@tarentis.com> wrote:
Le 01/02/2012 14:21, Lennart Regebro a écrit : With dvcs everyone got full history of zope libs. I personally find it a big pro for a free software.
While Lennart later rightly says, that svn also provides a full history, it is much slower. Even with the trac web interface that pov thankfully provides. Since I most often look for the history of something in SVN, I decided to finally make a git mirror for myself to quickly find the history of anything I might ever want. Since its for history only, I just imported the complete SVN repo as one git repo. So this is cannot be used as an alternative source for mr.developer. It is really only useful for history searching. Just for the case that somebody else might have an interest, I put it on github. Cloning will not make your harddisk explode, but you should have at least 750K Inodes available. A little vserver I used initially, did not have that many inodes. My dev machine has 6M Inodes (df -ih shows that) Even with the full svn history, looking up the full history of some file is superfast, with a regular hdd even. git status is something I woudn't do again, and updating the repo from svn is quite slow. If anybody is interested, the repo is here: https://github.com/do3cc/zope Best regards, Patrick
Hi Patrick On Mon, 2012-06-11 at 18:36 +0200, Patrick Gerken wrote: <snip>
Since I most often look for the history of something in SVN, I decided to finally make a git mirror for myself to quickly find the history of anything I might ever want. Since its for history only, I just imported the complete SVN repo as one git repo. So this is cannot be used as an alternative source for mr.developer. It is really only useful for history searching.
Just for the case that somebody else might have an interest, I put it on github. Cloning will not make your harddisk explode, but you should have at least 750K Inodes available. A little vserver I used initially, did not have that many inodes. My dev machine has 6M Inodes (df -ih shows that)
Even with the full svn history, looking up the full history of some file is superfast, with a regular hdd even. git status is something I woudn't do again, and updating the repo from svn is quite slow.
If anybody is interested, the repo is here:
Thanks for taking the effort to do this. The fact that one can see code diffs with "git log -p" is for me a killer feature. Do you also sync the git repo with new changes from the svn repo? J-C
On Tue, Jun 12, 2012 at 2:50 PM, Jan-Carel Brand <lists@opkode.com> wrote:
Do you also sync the git repo with new changes from the svn repo?
Yes, but unfortunately 1. It takes ages 2. I have to do it on my laptop because none of my servers has enough inodes for that task. I do it once a day at the moment.
On 11/17/2011 07:01 PM, Martin Aspeli wrote:
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.
I agree; actually "ZTK-like tracking set" is really already talking about doing releases, just like the ZTK has releases. And just like ZTK releases do, this needs some release management effort. Now I would advocate that Zope 4 releases mimic the ZTK in the way things are managed. Regards, Martijn
On Mon, Feb 6, 2012 at 4:41 PM, Martijn Faassen <faassen@startifact.com> wrote:
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.
not sure whom I'm quoting here, but: Zope 2 is special in that it still has one big library named Zope2 at its center. It's not just a collection of libraries. And a lot of the bigger changes being proposed need coordinated changes to multiple libraries. Like the __parent__ work or likely any non-trivial change to publication. You can likely evolve DateTime, Record, Missing or DocumentTermplate on their own - but that's not terribly exciting.
I agree; actually "ZTK-like tracking set" is really already talking about doing releases, just like the ZTK has releases. And just like ZTK releases do, this needs some release management effort.
Now I would advocate that Zope 4 releases mimic the ZTK in the way things are managed.
Just to clarify: Do you mean in terms of its release team? So instead of having one release manager constituting a team? A team representing the different consumer groups of Zope? Something like Plone, pure-CMF, non-CMF? In terms of its scope Zope 4 is meant to be a feature release, which needs coordination and decisions on what to include. That makes it a bit different from the ZTK, where the release team explicitly stays out of setting development direction and avoids influencing what happens in each library. So I'm not sure the ZTK release team model is directly applicable to Zope 4. The ZTK works fairly well for a mostly stable set of libraries, where not much happens and at most quarterly bug fix releases are needed. Hanno
On 17 November 2011 16:32, Tres Seaver <tseaver@palladion.com> wrote:
-----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 3, Grok and Pyramid have all innovated already. This is about making better use of those existing innovations and progressively removing code and dependencies from what is currently Zope2.
* 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.
I see Zope 4,5... very much as a transition path. I expect the different Zope2 based projects will move down that path at different speeds and that Plone will drive it by virtue of its larger developer base. Most of the other Zope2 based applications do not have the same wide community of developers to draw on.
* 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.
Of course. I expect that for some existing Zope2 applications that will be the easier path.
* 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.
At some point we will need to make a release that will receive bug fixes. The best point to do that will be the same time as a Plone release. This probably applies more to the central distribution (currently named Zope2), the other subsidiary distributions will certainly go their own way (as we've already seen with DateTime, ZPublisher, etc.), though any included with a Plone release will have a much larger number of people invested in making future bug fix 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.
The current repository on Github is indeed a scratchpad. We would want to do a better job of migrating usernames for a final migration (we would need an svn username -> name and email address map.)
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.
For better or worse, Git seems to have won the battle for mindshare. Personally I find hg much more pleasant to use, but I think most of us are in the same position as you of using git daily and the others less frequently. Plone, Pyramid, Chameleon, WebOb are all now developed with git on Github. Both Bit Bucket and Google Code have already added Git support and I've heard rumors Launchpad is working on it (you can already mirror branches to bzr there.)
- - 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).
This is probably as much a comment on my svn-fu, but at least for me I've find merging easier with git and hg. Maybe that's just down to having the history all there locally which makes the job of resolving conflicts easier.
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.
I think we should stick with Launchpad for bug tracking, it's the only one that really seems to work. Hopefully we can get the import working well enough for changeset bug updates to work, though I don't see it as a blocker. I believe there is wide support to hosting the code on github, not least among those who have so far been most interested in working on Zope 4. How do we put this to the Zope Foundation? Presumably the Zope Foundation will have similar concerns to the Plone Foundation surrounding copyright assignment. For the Plone Foundation I believe that basically came down to having a policy that those who push code into the repository (including by actioning pull requests) ensure that that code is under the contributor agreement, something that was – in principle at least – no different than with the existing subversion repository. I'm sure there are members of that Plone Foundation board who could provide information on that if it would be helpful to the Zope Foundation. Laurence
participants (17)
-
Alex Clark -
Alexandre Garel -
Charlie Clark -
Chris McDonough -
Chris Withers -
Hanno Schlichting -
Jan-Carel Brand -
Jens Vagelpohl -
Jim Fulton -
Jonathan Ballet -
Laurence Rowe -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Patrick Gerken -
Tres Seaver -
Wichert Akkerman