Re: [Zope3-dev] Re: Zope 3 releases?
On Mon, Oct 08, 2007 at 06:49:02PM -0400, Stephan Richter wrote: On Monday 08 October 2007 15:09, Tres Seaver wrote: Presuming agreement on the known good set (KGS) term, I would think that we have two candidates for what makes up platform releases Frozen Releases I started commenting this section until I saw the one below. I personally do not see much benefit from the frozen release. That said, it would be trivial to create one from the updateable version below. I have already scripts for this, which are checked in as part of Jim's PyPI mirror tool. A frozen release is very useful for some people (as long as it also gets security updates). -- Brian Sutherland ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
I'm not sure that library or collection of libraries is the right term for what we want to be. I think we've been using it because it stands in sharp contrast to application, which, BTW, isn't exactly what Zope 2 is. I think these terms were useful to make some points, but neither is accurate. FWIW, I have a fairly open mind on this topic. Lots of good points are being made. :) Jim On Oct 7, 2007, at 5:13 PM, Martijn Faassen wrote: Jim Fulton wrote: On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote: [snip] - We need a *realistic* (especially wrt available resources) process for managing releases. There are 2 aspects of this. We shouldn't make plans for which there aren't enough resources. We also shouldn't plan significant tasks that people won't care enough to work on. I think the classic Zope 3.4 release is a good example of a large effort that really wouldn't benefit many people, if any. Do you have a sort explanation on what is the missing resource? Is it, as it was for 3.3, lack of people-hours with knowledge in fixing the last bugs? I'm not entirely sure. I just observe that this doesn't seem to be making much progress. I think it's one of the drawbacks of taking an ecosystem/libraries approach instead of a application/framework style approach. An application or framework typically is an integrated whole that has a single version number. An ecosystem or set of libraries can be integrated (which Zope 3 is) but everything evolves at different rates and there's no single thing to install or talk about. I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants to be. I do think that such an approach needs to be supplemented by a framework approach (and I've been putting work into one way to do that). If Zope 3 is an ecosystem, a release of Zope 3 the ecosystem doesn't really make much sense. To follow the comparison with Linux distribution, it's more like a distribution of an ecosystem. I'd therefore suggest that the release of Zope 3.4, if it ever actually happens, will be the last release of Zope 3 the application server framework. I hope that besides Grok, some community will stand up that takes a less radical approach to building an application server on top of the Zope 3 ecosystem. People having existing applications in Zope 3 to maintain (like myself with the Document Library) will have a need for it, and Grok doesn't suit everyone's tastes anyway, especially people comfortable with existing Zope 3 practices. As I said elsewhere, I suggest we call this project not Zope 3 but something else, to avoid confusion with the Zope ecosystem (and also to avoid implying it's the clear successor to Zope 2. I think we can safely say by now that's not how history went). Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 06:56, Martijn Faassen wrote: Because we have endless confusion between Zope 3 the ecosystem and Zope 3 the web application framework. For me it is exactly the same. Zope 3 is a Web application server. Zope 2 uses many components of the Zope 3 Web application server. If you go and make a separate Zope 3 the web application framework and you can get away with just writing a buildout.cfg, then be happy. Just call it something else, as otherwise people will confuse it a lot with the exploded Zope 3 libraries. They don't *have* to use this particular web framework in order to use Zope 3. They can also use Zope 2, or Grok. But I consider the crafted set of libraries the Zope 3 application server. Whether you use just some of its components, choose a different WSGI server, or exchange functionality is totally irrelevant; it just proves how good the Zope 3 application server is. If Zope 3 is like a linux distribution, we'll have to manage it like a linux distribution does. A linux distribution has releases, but it doesn't have releases of something individual you install and run. It just has semi-frozen ecosystems being released once every while. Right, and I think this is what we need to do for Zope 3. This is what download.zope.org/zope3.4 and the KGS idea is all about. You can't do this and at the same time manage Zope 3 as an application, I think. It's an either-or. I have never defended the idea of a Zope 3 application. In fact, a lot of my efforts in Zope 3 right now are to get rid of the ZMI in my projects. application server != application The stable sets for the web application server are defined by those people who develop the Zope 3 web application server. The people who develop the web application server make choices that other users of Zope 3 technology might not make: perhaps to use Twisted for a web server. Perhaps to use paste for configuration, or *not* use paste for configuration. They might at some point decide that z3c.form is the default form framework that is documented in Zope 3 tutorials, instead of zc.formlib. Thus, the KGS should include all packages the sub-communities care about. For example download.zope.org/zope3.4 has both z3c.form and zope.formlib. Again, we should look at Linux distributions. They have a very healthy process for including and excluding packages. The community makes requests of packages to be included, then they are tested and if all is well, they are added to the next version of the distribution. If a package looses support and becomes so outdated that it does not work with the latest set of packages anymore, it is removed. Hopefully the users of the Zope 3 technology can work together on defining stable sets, but probably not for the entire range: Grok has some extra dependencies that Zope 2 may not have, and vice versa, for instance. Well, I would like to have a KGS that can be used by all user projects, including Zope 2 and Grok. If any of the user projects want to nail additional versions, they can do so and I would be glad helping to develop technology to make this happen. The Zope 3 web application server is not primarily what the Zope 3 project appears to be developing. I strongly suspect there are more users of Zope 3 technology within the Plone community than outside it, for instance. If the Zope 3 project cared about developing a web server, you'd think it would do a somewhat better job presenting it to the outside world on a web page, and that there'd be more people to actually make releases? I think we have very different definitions of application server. For me web server != application server. In Zope 3's case I could care less what the Web server is. For me, the publisher is really the server component. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
Hey, Stephan, I tried to reply to your points but I realized I was getting lost in a sea of semantics and that it wasn't useful. The Zope 3 web application server is not primarily what the Zope 3 project appears to be developing. I strongly suspect there are more users of Zope 3 technology within the Plone community than outside it, for instance. If the Zope 3 project cared about developing a web server, you'd think it would do a somewhat better job presenting it to the outside world on a web page, and that there'd be more people to actually make releases? I think we have very different definitions of application server. For me web server != application server. In Zope 3's case I could care less what the Web server is. For me, the publisher is really the server component. I meant to write web application server, but I didn't write the word application, sorry. I'd like to see a separation between what you consider to be not only closely allied but *identical*: the pool of Zope 3 components, managed together by *all* the communities that make use of Zope 3 technologies, and the Zope 3 application server, where you go to some web site explaining what it's all about, and then download and install and get some script for to start some webserver so you can access it, read tutorials on and try to see Hello world on your screen with. Of course since to you there is no difference between the two, it gets hard to communicate. The communities that use Zope 3 technologies all have an interest in improving the common components, and also in distributing such common components for reuse. Our collective community could be called the Zope community, where Zope is like a Linux distribution that different systems make use of, with the major difference that we actually develop most of those packages within the community instead of mostly reusing what's developed outside. The Zope community has always been in the business of building software that can be used to build (web) applications. For years now we haven't had a single unified piece as we did when Zope 2 was (almost) the only game in town in the Zope world. These days, we have a whole host of related pieces that people can download and install and build software on top of. We have Zope 2, Zope 2 + Five, Zope 2 + CMF, Zope 2 + CMF + Five, original Zope 3, and Zope Grok. What's more we've had things build on top of this that also have aspects of frameworks or platforms, such as Plone or Silva. We've also always had components and systems that we use in our application servers, but could also be used separately: bobo, the ZODB, zope.interface, buildout, zope.pagetemplate. We don't have a linear evolution of a single platform at all, even though for a while we first intended and then pretended it was so with the naming of Zope 2 and Zope 3. We've stopped pretending for a while, I think. Instead, we have different communities that share underlying philosophies and technologies, and interact with each other within the Zope community. The one thing all these systems have had in common for the last years is that they all share Zope 3 technologies. If anything is the Zope platform it's this pool of Zope 3 technologies. The Zope development community is about the Zope platform. How to improve the platform? We've done this by improving them, adding to them, making them easier to evolve independently, supplementing them with technology like eggs and buildout, testing them, and making them easier to manage. The Zope community is also about the things we build on top of the Zope platform: Zope 2, Zope 3, CMF, Grok, etc. The nice thing about these is that they make choices for you. If you use Zope 2.10 today, you know what you have to deal with and you can rely on what you deal with. With Zope 3.3 it was the same story, and so it is for Grok. These we can market and offer for download and install. These things is what we can write tutorials for. So, the Zope community is a community of communities that are tied together by their common interest in the Zope platform, on top of which they build applications, web application frameworks and web application servers. The Zope platform allows you to roll your own software directly on top of it if you'd like, but typically you'd make use of one of the pre-packaged varieties such as Zope 2, Zope 3 or Grok. All of them are Zope. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 11:06, Martijn Faassen wrote: Stephan, I tried to reply to your points but I realized I was getting lost in a sea of semantics and that it wasn't useful. I agree I'd like to see a separation between what you consider to be not only closely allied but *identical*: the pool of Zope 3 components, managed together by *all* the communities that make use of Zope 3 technologies, and the Zope 3 application server, where you go to some web site explaining what it's all about, and then download and install and get some script for to start some webserver so you can access it, read tutorials on and try to see Hello world on your screen with. Of course since to you there is no difference between the two, it gets hard to communicate. Exactely. Because it might not be so easy to just click and go. Let's take an example, because I think it makes it more clear. For me z3c.formdemo is a good example of a small Zope 3 application. It is built on top of the Zope 3 Web application server. But in order to get it working, I did not have to install anything special. I just use the libraries. *I do not want to add technology just to match desired terminology.* Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Monday 08 October 2007 15:09, Tres Seaver wrote: Presuming agreement on the known good set (KGS) term, I would think that we have two candidates for what makes up platform releases Frozen Releases I started commenting this section until I saw the one below. I personally do not see much benefit from the frozen release. That said, it would be trivial to create one from the updateable version below. I have already scripts for this, which are checked in as part of Jim's PyPI mirror tool. Updatable Platform Releases --- An updatable platform release would consist of: - A KGS whose index pages were manually updated from time to time with carefully-selected new distributions of existing packges. - An installation regime, as above, which uses the KGS as its 'index_url', but *pins no packages* (whether in the meta egg, buildout.cfg, or whatever). o This regime should also contain / bootstrap scripts which couls be used to do automated updates from the KGS, like 'yum update' / 'apt-get upgrade'. This is pretty much done. See http://download.zope.org/zope3.4. I have checked in the tools in zc.mirrorcheeseshopslashsimple. Buildout itself serves as an equivalent to ``yum update`` or ``apt-get upgrade``. You can simply say ``./bin/buildout``. Without the -N option it will fetch the latest version, but the KGS guarantees that this will at most be a bug fix. In this case, generating the meta egg (or equivalent) should be unneeded: that egg could just be managed within the KGS itself. In a typical environment, the meta egg would likely never be updated all all (because it contains no software beyond the parts used to generate the environment). Yep. Such a relase would be analogous to an installed Linux distribution, with update repositories pre-configured. Exactely! Maintaining the KGS in this case is harder, and could probably use a little more tooling. Once we have the tools, then tweaking them to allow generating a frozen release will be simple. In that mode, the two flavors of release here could be thought of as like tags and branches in the CVS sense (not SVN, which doesn't really have tags). Yep, I agree. The usefulness of tags other than for generating a full release is questionable in my opinion, but I still agree with your ananlisys. :-) Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On 10/7/07, Brandon Craig Rhodes [EMAIL PROTECTED] wrote: There is danger here. Many in the industry consider Linux to be an absolute disaster - because after you develop an application on one distribution, you can spend months trying to support customers who attempt to run it on other distributions! In the wider Unix world things are even worse. Tools like autoconf absorb months and years of developer effort to simply get products to compile everywhere. Right, but the problem I think is that people say that applications run on Linux, and also spend time to make them do so, and that needs a lot of time spent. I think that an application running on a pure Zope 3 would run also on Grok, but it would be entirely possible to make another application that for example doesn't use the ZODB at all, but still uses the rest of the Zope3 ecosystem. And an application running on Zope 3.3, would not run on such a distribution. So if we make Zope3 less of an application and more of a platform/environment/ecosystem, we should probably not say that anything runs on Zope3, and that would then solve that problem. Applications would *run on* Grok, but *use* zope 3. But I suspect that we then end up with your Python model, right? :-) Now, it sounds like Zope is about to stop being like Python and start being like the current Wild West of Linux distributions. If I want to write a WebWidget in the future, and want it to work with Grok, and Zope on Wheels, and ZopeSprockets, and whatever other frameworks might come along, then I will be faced with situations like Well, Grok has already moved up to zope.security 3.7, which means I can use key cards natively! Hmm, but the other frameworks have not upgraded past 3.6; I will have to special-case key-cards for them. On the other hand, Grok stayed with zope.templates 3.5 because they piled so many extensions on top that they didn't get time to redevelop them for 3.6, so I'm going to have to fake push-masking in Grok... Y, I see your point. But is this avoidable at all? Even with more fixed sets of versions we have this exact problem already today. I would like to use utilities, but Plone 2.5 is still on Zope 2.9 which has a slightly different utility implementation than Plone 3, so I'm going to have to specialcase for that, and at the same time I'd like to use this under Grok which has moved on to zope 3.4... and so on. I think that with the granular versions we get with eggs, it's in fact gonna be *easier* to avoid this stuff, because I could in my application update to a newer version of the module I need, and it wouldn't actually break anything except in those cases where the module breaks backwards compatibility, which isn't supposed to happen, except in some extreme circumstances nowadays. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
IMO, the Python standard library and batteries included is a mess. Despite being a Python contributor, I've very unmotivated to be a contributor because the time lag between contributing and deriving benefit from the contributions is too long. People had similar complaints about Zope releases. I'll note that the problem is exacerbated by the incompatibilities that (to some degree inevitably) often occur in Python releases. Big-bang releases don't prevent update problems. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On Sunday 07 October 2007 17:13, Martijn Faassen wrote: I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants to be. I do think that such an approach needs to be supplemented by a framework approach (and I've been putting work into one way to do that). Why? I have no need for anything on top of Zope 3. I just need to have stable sets of packages. If Zope 3 is an ecosystem, a release of Zope 3 the ecosystem doesn't really make much sense. To follow the comparison with Linux distribution, it's more like a distribution of an ecosystem. I don't understand that sentence. I'd therefore suggest that the release of Zope 3.4, if it ever actually happens, will be the last release of Zope 3 the application server framework. That would be really bad. Who defines stable sets then? Again, I think there is absolutely no need for another framework on top of Zope 3. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 releases?
On 10/7/07, Martijn Faassen [EMAIL PROTECTED] wrote: While I see Brandon making good points, I also agree with this: the motivation to contribute to the Python standard library is reduced because of big bang releases. I think the main reason is that you need to wait so long to see your work in print so you can use it yourself. Yup. This may be one of the reasons behind the lack of kicking upwards, as I outlined here: http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2005_04_11_sickness_zope -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com