Re: [Zope3-dev] Re: Zope 3 releases?

2007-10-10 Thread Brian Sutherland
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?

2007-10-08 Thread Jim Fulton


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?

2007-10-08 Thread Stephan Richter
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?

2007-10-08 Thread Martijn Faassen
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?

2007-10-08 Thread Stephan Richter
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?

2007-10-08 Thread Stephan Richter
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?

2007-10-07 Thread Lennart Regebro
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?

2007-10-07 Thread Jim Fulton
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?

2007-10-07 Thread Stephan Richter
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?

2007-10-07 Thread Lennart Regebro
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