[Zope-dev] Zope 4 release management

Tue Jan 31 23:05:34 UTC 2012

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

-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 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-----
>
> _______________________________________________
> Zope-Dev maillist  -  Zope-Dev at 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