[Zope3-dev] Re: December release post-mortem
Martijn Faassen wrote: >>> Yes, but Zope 2 included *less* than Zope 3 in the most recent >>> release, and I'd like *all* packages that are in a Zope 3 release to >>> be available in a Zope 2 release. I.e. Five doesn't want packages >>> that aren't in a Zope 3 release, but not less either. >> >> I'm surprised that it included less. > > It was a bug, and I think some of it already got resolved (Philipp would > know more), but it wasn't noticed until fairly late, as during > development such dependencies are development. It included less due to an oversight on my side. I forgot to make the Zope 2 release depend on certain new zope.app packages that zope.app didn't already depend on. They were not included in Zope 2.9b1, but 2.9b2 quickly fixed that. It was my mistake. I don't think anything would've made it easier catching that mistake other than reports from the people. Also, it's a mute point now (please let's bury it!) as b2 already fixed it. While I got this email open, I'd like to quickly add my EUR0.02 as a summary of this thread: * Breaking Zope (3 that is) into subprojects is extremely useful. zope.testing was a good example, the next things should be zope.interface+zope.schema and zope.pagetemplate+zope.tales+zope.tal etc because there are actually standalone releases of these things or at least people using these things separately from Zope. * Moving things that aren't immanent to the Zope 3 application server out of zope.app is also a good thing. I suspect this is mostly a mechanical change (dropping the 'app' in the import name). Ideally this should indeed leave us with a zope.app that is so Zope3-specific that it isn't of any use for Zope 2. * We should indeed avoid having to include certain Zope 3 things into Zope 2 that don't make any sense in Zope 2. The whole zope.app.twisted machinery is an example. Currently we're not running zope.app tests in Zope 2 because we would have to stitch in twisted into Zope 2 svn! * Zope 2 should continue to use and provide as much Zope 3 functionality as Zope 3 does. This "policy" brought us zope.formlib to Zope 2.9 which is already being enjoyed by some Five developers! * We should get rid of vendor imports such as pytz, docutils and those testbrowser dependencies. Eggs will make this very trivial. We won't even be concerned about development mode or not because we're not modifying them anyways. I think the decision for time-based releases is a success, mostly because I already know when a new Zope release is to expected and roughly what features it'll bring. As someone who puts a lot of effort in Zope 3 documentation I find this extremely valuable as a planning asset. As for the December release itself, I'm not too impressed. On the Five/Zope 2 side of things it was more than people bargained for, namely the port of Five to Zope 3.2 and the packaging of Zope 2 with zpkg. It might be due to the fact that this was our first time-based release and people were just used to releases being postponed when they didn't find the time to commit to a schedule. Obviously this we can't continue like this in the future. If we move the release up to May (I'm +1) then feature freeze is in April. That effectively leaves us not much more than two months worth of time for work on Zope 3.3/2.10. What I want to say with this is that the right time to work on Zope 3.3/2.10 is *now*, not some time in the summer. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: December release post-mortem
On Thu, Jan 19, 2006 at 07:00:43AM -0500, Jim Fulton wrote: | Stephan Richter wrote: | >On Wednesday 18 January 2006 19:09, Jim Fulton wrote: | > | >>>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. | >> | >>Right. If eggs work out, then a respository check out will be a lot | >>smaller, but will download needed eggs. This would be a replacement of | >>the | >>use of externals we have now. | > | > | >Oh, this will make development so much more tedious. Let's say | >zope.testbrowser is an egg and I discover a bug in zope.textbrowser while | >doing some other Zope 3 development, I have to check out zope.testbrowser, | >fix the bug, check it in, download the new egg and hope it fixed my Zope 3 | >problem. Honestly this is far too much and I will at most make a bug | >report. | | I beliave that Eggs have a development mode in which you can work on the | source. Concerning eggs, I have read the front-page description but haven't worked with them. However I do have experience with developing Eclipse plugins and the concept sounds about the same. Eggs seem more akin to Eclipse plugins than to Java jars. Here's how it works in eclipse, and I believe that "development mode" of the eggs is the same: in your workspace you check out all of the plugins/eggs that you are working on. When you launch the application, the system will use the plugins/eggs from the workspace as they are in the directory structure. You do not need to separately modify, build, release, and install a dependent plugin/egg. I think this will work well to make zope's packaging and distribution as modular as the code itself is. Each plugin/egg can be released in its own right at its own time (as applicable) and will be easy for other applications to reuse various components and, at least as I see it from my eclipse experience, will not hurt the development process of zope. -D -- Whoever gives heed to instruction prospers, and blessed is he who trusts in the Lord. Proverbs 16:20 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: 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 :-) Isn't this always the case? :)(ie with all 2.x.0 releses) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
