[Zope-dev] Re: [Zope3-dev] December release post-mortem

[Martijn Faassen]

Hey,

First, I'd like to thank you and everyone involved in the Zope 2 and
Zope 3 releases for making this time-based release in what I consider to
be a smashing success. Thanks for all the hard work! Things were late a 
bit, some things are imperfect, but we in the community are already 
feeling the positive effects of being able to plan for releases. I want 
Jim to be sure he realizes it's a success from other's perspective as well.

Several great features are probably in Zope 2 now in part due to the
time-based release system. I want to point out for special attention
Florent's great work on making Zope 3 style events work with Zope 2.
This is no less than fantastic. This kind of work might've lingered for 
a long time if release dates were uncertain.


Jim Fulton wrote:

> Now that I've had a week or so to recover from making the Zope 3 
> releases, I'd like to look at how we did on our first timed releases.

Thanks for doing the post-mortem. Very valuable.

> Of course, the releases didn't happen in December.  In fact, the Zope
> 2 Windows release still hasn't happened.
> 
> That we were late isn't a great surprise, given that this was our
> first timed release.  The beginning of the release cycle was delayed 
> because people didn't really realize/remember that we needed to
> freeze by November 1.

[snip]

> In the future, if someone introduces a major change, they *must* be 
> committed to be available to deal with issues that arise during the 
> release cycle.  Perhaps we need to pick different release dates to 
> avoid holidays.  Stephan has suggested moving the dates up to 
> November/May rather than December/June.

+1 to moving the dates to be further away from holiday seasons.

> And then there are the Windows releases.  Making Zope 2 windows
> releases is very painful and there don't seem to be many people
> willing to help.
[snip]

Getting a dedicated volunteer to work on Windows releases seems to be
hard. I've tried with lxml and while several people have successfully
compiled it on Windows, and several people volunteered to help with
releases, it still hasn't gotten off the ground.

I'm glad the decision was made to let Windows not be a release blocker.
We're not the only one with this problem. A few months ago I was reading
the Apache HTTP server mailing lists and to my surprise found a thread
talking about how their process was failing. The Apache HTTP server has
a very strict policy concerning changes to the codebase; they have to be
vetted by other programmers before they can go in. There were some 
problems pointed out about this procedure slowing things down, but 
interestingly enough one of the blockers for making new releases of 
Apache was the volunteers not knowing how to do a Windows release. :)

> I think that packaging is a significant challenge to our release
> process. The Zope 2 release was complicated by the use of zpkg.  The
> zpkg system was developed to allow us to decouple the Zope 3
> repository and releases. It was too painful to mold the repository to
> fleeting release decisions. We wanted people to put experimental and
> add-on applications in the repository so that they would be tested as
> we rapidly evolved things. While zpkg was crucial for the last 3
> releases, I don't think it provides the best long-term approach.
> Rather than extracting a release from a larger repository tree, I
> think it would be better, going forward, to assemble a release from 
> smaller individual repository trees or from releases. 

I'm glad this is being given a re-think.

How do you assemble releases 'from releases'? I'm not sure I understand 
that. You mean make a Zope 2 release using a Zope 3 release?

You know my position concerning the repository and the release; I'd 
prefer them to be kept as similar as possible to simplify the release 
process. I hope we can go in that direction. It also makes things more 
predictable to developers. We noticed that some Zope 3 packages weren't 
packaged into Zope 2 after the release, even though in a developer's 
sandbox of Zope 2 they were there.

As a side issue: From the perspective of Five, it is beneficial to have 
as much Zope 3 code included into Zope 2 releases, as that gives us an 
opportunity to start using this functionality right away, exposing it to 
Zope 2, without waiting for a new release.

[snip]
> We have begun to see Zope 3 decomposed into separate projects knit
> together via svn:externals.  I'd like to see that trend continue and
> to perhaps switch to making the knitting process use eggs,  I'd like
> to leverage eggs to make the release process much simpler.  It should
> be easy for people to make releases so that there could easily be
> multiple distributions aimed at different needs and expectations.

I'll repeat here that I think there's much value in trying to keep the 
mapping of the SVN repository very similar to what is actually released. 
   (If you're interested I can try to explain some of my thinking a bit 
deeply.) Eggs are a nice distribution mechanism, but I'd also want the 
knitting process to work for a SVN checkout -- developers working with 
SVN need to be very easily work with a 'knitted' version, so perhaps 
svn:externals will remain a valuable tool.

> As part of this decomposition, we need to make zope.app much smaller.
>  Early in Zope 3 development, I proposed a simple rule for
> organization of the repository: Anything that depended on zope.app
> went in zope.app. Anything else went in zope.  If there was doubt,
> put it in zope.app.  I think that served us well at the time, but I
> think we've moved beyond that,  I'd like to migrate most of zope.app
> elsewhere.  Zope 2.10 should not include zope.app.

This worries me; Five is currently using massive quantities of code in 
zope.app, and as expressed above, I value Five having access to 
potentially all Zope 3 code that's in a Zope 3 release.

> Note that I'm banking heavily on eggs without personally having
> worked with them much.  I'm very hopeful that we can make them work
> for us.
> 
> In the end, I consider the "December" release to be largely
> successful, given the challenges.

Agreed.

> These were some of my reactions to this first attempt at time-based 
> releases. What do other folks think?

A great success! Thank you!

> Given that the Zope Foudation will be formed during this next release
>  cycle, I think this is a good time to take stock and think about how
> to move forward,

Included were some of my thoughts.

Regards,

Martijn