[Zope-dev] December release post-mortem
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. 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. The release was delayed past December in large part due to problems found with the Zope 3 Twisted server. In retrospect, I should have accepted these, made ZServer the default and marked the twisted server experimental. Instead, I spent 2 weeks thinking the resolution only needed a few more hours of work. I should have known better. I'm disappointed that the people pushing the Twisted server didn't provide more help during this period, but it was a holiday time and one of the main drivers, Stephan, warned way in advance that we shouldn't be finishing a release during a holiday period. Of course, we should have been finishing the release in early December. 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. 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. We've avoided the pain for Zope 3 by being less ambitious. We let distutils do most of the work. The result is that making a windows release takes minutes and is highly automated, but the experience for the end user is less than ideal, Many would rightfully argue that it is inadequate. What we need is a release process that is as easy as the Zope 3 windows release process and produces a result as usable as the Zope 2 windows release. I'm not sure exactly what the answer is, but I am sure we need to take a fresh approach. Whatever approach we take needs to be highly automated and must not require a lot of specialized Windows expertise. 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. This is feasible because: - Python is finally growing a packaging system with eggs, - buildbot provides a mechanism for getting things tested without putting everything in a single repository, and - the new test runner's layer makes it feasible to define independent functional tests for packages. 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. 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. 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. These were some of my reactions to this first attempt at time-based releases. What do other folks think? 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, Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or
Re: [Zope-dev] December release post-mortem
--On 18. Januar 2006 07:36:35 -0500 Jim Fulton [EMAIL PROTECTED] wrote: 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 for moving the dates. Speaking for the Zope 2 release: - the zpkg chances were introduced very late and it was somewhat annoying to deal with this almost untested changes during the betas (not blaming Philipp here, he has done a tremendous lot of work) In addition such major changes should happen on a branch and not on the trunk and such changes should be started early before the next release (not week or two before the first beta). 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. We've avoided the pain for Zope 3 by being less ambitious. We let distutils do most of the work. The result is that making a windows release takes minutes and is highly automated, but the experience for the end user is less than ideal, Many would rightfully argue that it is inadequate. What we need is a release process that is as easy as the Zope 3 windows release process and produces a result as usable as the Zope 2 windows release. I'm not sure exactly what the answer is, but I am sure we need to take a fresh approach. Whatever approach we take needs to be highly automated and must not require a lot of specialized Windows expertise. The basic problem with the windows release is that there is currently nobody in charge for the windows release (although Tim is again doing working on the Windows side, ALL HAIL TIM). 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. It was basically a birth with some pain :-) These were some of my reactions to this first attempt at time-based releases. What do other folks think? I think 2.9.0 is the _real_ 2.9 beta which will be widely used by ppl :-) -aj pgp82mUIHWcDt.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] December release post-mortem
Andreas Jung wrote: ... The basic problem with the windows release is that there is currently nobody in charge for the windows release (although Tim is again doing working on the Windows side, ALL HAIL TIM). I'll repeat or emphasis that the windows release process needs to be simple enough that *I* can do it. This means that the process should be simple and well documented enough that someone like me can follow it without thinking. Thinking is hard. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] December release post-mortem
Andreas Jung wrote: ... I think 2.9.0 is the _real_ 2.9 beta which will be widely used by ppl :-) I could be wrong, but if we stick to a 6-month release cycle for feature releases, I don't think there is going to be much appetite for bug-fix releases, except in extreme cases, and I think it will be more important to get the feature releases right. Of course, this required commitment from the community. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] December release post-mortem
--On 18. Januar 2006 10:31:03 -0500 Jim Fulton [EMAIL PROTECTED] wrote: Andreas Jung wrote: ... The basic problem with the windows release is that there is currently nobody in charge for the windows release (although Tim is again doing working on the Windows side, ALL HAIL TIM). I'll repeat or emphasis that the windows release process needs to be simple enough that *I* can do it. Well, that's a perfect goal :-) But my experience with doing slightly simple programming tasks on Windows is that Windows will slap you wherever possible - even when you're trying to solve simple problems. I stopped dreaming that anything on Windows works as it should. just-being-a-frustrated-windows-hacker-(sometimes), Andreas pgp18hbgLuPnZ.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] December release post-mortem
On Wed, Jan 18, 2006 at 04:37:12PM +0100, Andreas Jung wrote: | I'll repeat or emphasis that the windows release process needs to | be simple enough that *I* can do it. | | Well, that's a perfect goal :-) But my experience with doing slightly | simple programming tasks on Windows is that Windows will slap you wherever | possible - even when you're trying to solve simple problems. I stopped | dreaming that anything on Windows works as it should. I'll add to that that I used to think this way, too, but Mark Hammond slowly convinced me otherwise. Today I have the opinion that no matter what other people say, Windows is actually superior to *anything* I've seen in Linux or OS X, except for the networking stack and process management. COM, for example, is very cool stuff. You should see some of the stuff Mark has done that allows one to call pretty much any Python object via COM from any language that supports COM as long as the Python object has a interface declaration using 'zope.interface'. I'm still waiting to see something like COM on the Linux world. Over with the bashing, back to the topic now. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] December release post-mortem
Sidnei da Silva wrote: [snip OS flamewar in the bud] :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope3-dev] Re: [Zope-dev] December release post-mortem
Jim Fulton wrote: Andreas Jung wrote: ... I think 2.9.0 is the _real_ 2.9 beta which will be widely used by ppl :-) I could be wrong, but if we stick to a 6-month release cycle for feature releases, I don't think there is going to be much appetite for bug-fix releases, except in extreme cases, and I think it will be more important to get the feature releases right. I expect a fairly normal progression of bugfix releases myself, except that hopefully less features will sneak in as has been the case with older Zope 2.x releases. So we'll see less bugfix releases, but only because we're not fixing features in them. :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
