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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
