l at lrowe
Nov 17, 2011, 10:55 AM
Post #9 of 31
(384 views)
Permalink
|
On 17 November 2011 16:32, Tres Seaver <tseaver [at] palladion> 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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )
|
signature.asc
1
