On Fri, Mar 18, 2005 at 05:42:05PM +0100, Andreas Jung wrote:

--On Freitag, 18. M?rz 2005 11:22 Uhr -0500 Brian Lloyd <brian@zope.com> wrote:

...

- In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work.

I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release:

[snip todos] I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8.. Do some of these have something to do with a change to Python 2.4, by the way? It's a bit unclear to me what version of Python this release is targetting. Regards, Martijn

Andreas Jung wrote:

--On Freitag, 18. März 2005 18:03 Uhr +0100 Martijn Faassen <faassen@infrae.com> wrote:

...

On Fri, Mar 18, 2005 at 05:42:05PM +0100, Andreas Jung wrote:

...

--On Freitag, 18. M?rz 2005 11:22 Uhr -0500 Brian Lloyd <brian@zope.com> wrote:

...

- In the next few days at most, after a few loose ends are wrapped up, we'll ask Andreas to make a 2.8 beta 1 release. While Jim still has a few things to do, people will be able to start using the beta for real work.

I think that the following outstanding to-dos for Zope 2.8 should be completed before a beta release:

[snip todos]

I understand that Jim won't have time to do these until mid-april. Is it absolutely impossible to ship a beta which is 'non optimized' or something? I mean, we got Silva and Plone running on Zope 2.8..

A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality.

I don't think we have new features on the to do list. These are all bug fixes or optimizations. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

Andreas Jung wrote:

--On Freitag, 18. März 2005 12:31 Uhr -0500 Jim Fulton <jim@zope.com> wrote:

...

...

A beta release should be feature-complete means it should contain everything that will be part of the final release. A beta should not development release where things are subject to change in some way. We can do an alpha 2 of course with everything you want but as long as there is longer list of outstanding issues I won't consider the current SVN trunk as beta quality.

I don't think we have new features on the to do list. These are all bug fixes or optimizations.

My point is: we are adding a lot of new code to the Zope 2 core - it does not matter if there is a tight or a loose coupling between Z2 and Z3 - and calling it beta. Any code going into a beta should have been tested within at least one alpha release. In my opinion alpha releases have the task to figure out major integration problems. Such problems should be solved before the beta cycle. My fear is that we are running into the same release problems as with the Plone 2.0 release (lots of development and changes during the beta phase).

My suggestion: let's make an Zope 2.8 alpha 2 in the first week of April and let us nail down a release date for beta 1 (in early May). So there is enough time for interested people to test the Z3 integration and for others to fix outstanding issues in the Zope 2 core. This gives everyone (I have the Plone, CPS, Silva communities in mind) the possibility to check out if there is something missing in Zope 2.8 *before* we are going into a *short* beta release cycle with hopefully a final version in Q2. Any comments?

I think this makes a lot of sense. Of course, it's up to you and Brian. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

--On Samstag, 19. März 2005 18:15 Uhr +0100 Martijn Faassen <faassen@infrae.com> wrote:

No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed.

I have update the 2.8 wiki with the planned release schedule.

I'd prefer a shorter cycle, with an alpha 2 this month, a beta in april, and a release at the latest in may. I would also very much like to have a release date set and committed to. I don't like to hear "hopefully a final version in Q2" and such estimates in relation to Zope releases; it almost *invites* further delays.

The latest delays are basically caused by missing contributions from the community. Since 2.8a1 in October 2004 most fixes were made by Tim, Jim, Stefan Holek and myself.

We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested.

You are arguing with the Z3/Five hat on. Having a reliable Zope 2.8 version with MVCC support is much more important to most people than having a perfect Five support. So the primary goal of the Zope 2.8 release is to have a stable successor release for Zope 2.7.

I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed.

I hope everyone is really commited. We'll see how far we can get with this approach. Andreas

Andreas Jung wrote:

--On Samstag, 19. März 2005 18:15 Uhr +0100 Martijn Faassen <faassen@infrae.com> wrote:

...

No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed.

I have update the 2.8 wiki with the planned release schedule.

Thanks! Looks good. I'll commit some time to make this work. [snip]

...

We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested.

You are arguing with the Z3/Five hat on. Having a reliable Zope 2.8 version with MVCC support is much more important to most people than having a perfect Five support. So the primary goal of the Zope 2.8 release is to have a stable successor release for Zope 2.7.

True, MVCC is important and MVCC needs to be tested, but I believe unfortunately the best test for it will be in real world production use, and a release will happen before most people risk that... I believe you'll find it interesting that there was a sprint full of people who were motivated to hack on Zope 2.8 because of the Zope 3 aspect, not the MVCC aspect. I myself proposed several times early in the week to go without Five, but people objected. I know I'm hard to trust as a source of this, as I have the 'Five hat' on, but it's so anyway. :)

...

I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed.

I hope everyone is really commited. We'll see how far we can get with this approach.

I definitely hope people are indeed committed too. :) Regards, Martijn

Martijn Faassen wrote: ...

Do some of these have something to do with a change to Python 2.4, by the way?

No.

It's a bit unclear to me what version of Python this release is targetting.

2.3 Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

Jens Vagelpohl wrote: [snip]

...

It appears there is an assumption that merging Z2 and Z3 code within Z2 itself is an unmitigated good thing, but IMHO, each is complicated enough in their own right that I'd personally prefer to be dealing with one or the other at any given time and not both. This isn't exactly idle whining either, I need to do this when I maintain Z4I code, and it's definitely not a walk in the park; it's moderately difficult to do and also difficult find people who have the skills to help too.

Right on. Now, I have no idea how similar or different the Z3-Z2 marriage in 2.8 is to that unholy alliance that is used for Z4I, but working on it for Z4I is an exercise in frustration every time I had to do it.

If Z4I uses the Zope 2 -> Zope 3 interfaces compatibility package, then it's quite different. Let's just put it this way; I don't know anything about Z4I beyond the existence of this interface package, which is something I didn't like and didn't use in Five. The two technologies therefore appear quite distinct.. You can try Five with Zope 2.7 by downloading it, putting Zope X3.0's code on the python path, and starting Zope. We've already used Five in Zope 2.7, in a Silva, CPS and Plone context. These are complicated Zope 2 applications, and with Five installed, they remain working as before. Regards, Martijn

On Fri, 2005-03-18 at 13:45, Brian Lloyd wrote:

A lot of time was spent talking about these (legitimate) concerns - unfortunately it will probably take a little time to distill all of that communication to the community. But let me take a shot ;)

There are several different groups, with different goals and concerns, who are involved here:

A: Z2 developers that don't care right now about Z3

B: Z2 developers that care about Z3, but can't effectively use anything Z3 related right now because it is not practical or possible to switch wholesale and there is no bridge to Z3 that doesn't require throwing away existing investments in Z2

C: Z3 developers that don't care about Z2 anymore, often because they dont have existing investments in Z2

There are a significant and growing number of people in group B.

Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases. While it wouldn't be the end of the world or anything, I suspect some dependencies will inevitably creep into the Zope 2 core on Zope 3 packages, and maintaining an older codebase can be pretty painful. The testing requirements for making sure that changes that Z2 coders make to Z3 work both in Z2 and Z3 is a pretty high bar, just as vice versa. In the past, I've seen efforts like this turn into an effective fork as a result.

At the paris sprint, we were looking for a way to:

- Allow folks in group B to start taking advantage of (and developing an interest in and contributing to!) Zope 3 technologies

- Make sure that group A would not be 'forced' to do anything they don't want to do

- Make sure that group C would not be 'forced' to do anything they don't want to do

I feel that the approach of integrating Five into Zope officially does a pretty good job of meeting those goals. We added the Five product and a snapshot of Zope X3.0 into the core so that people could have a reliable baseline 'out of the box'.

That integration touched almost nothing in the Z2 code (one or two things that were previously done as monkey patches were un-monkeyed, but that's about it).

The Z3 code (and the Five code) just sits there unused unless you choose to use it, so Zope3 code breaking Z2 apps is not really a concern.

That's good to know.

But is there and available, so people can begin to plot their own migration paths based on their own situations.

Please correct me if I'm wrong here but I get the sense that Five is less of a "migration path" from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to "straight Z3" will always be more or less a rewrite, no?

Like other areas of Z2 (and Z3, for that matter), contributors tend to develop areas of expertise. A new area of expertise for Z2 going forward will be the Five/Z3 integration, and there will be a set of devs who will likely focus on that aspect. I don't expect that the fact that Five and Z3 integration exists will make life any harder for someone who focuses on purely Z2 aspects of the core anytime soon.

So the short answer is, we tried really hard to make sure to take an approach where z3 integration would not actively break zope2 in any way or force people into any particular direction.

Excellent, that's what I was hoping.

I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out.

For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;)

Yup... I'm still a bit skeptical but if other folks are committed to maintenance I'd be less so. - C

On Fri, 2005-03-18 at 14:44, Brian Lloyd wrote:

It won't turn into a fork. Right now there is a lot of discussion going on about the 'right' way to manage Z3 releases -- we'll need to decide on a Z2 release policy that takes that into account. I think the goal for Z2 will be to include the latest stable z3 possible. Some have suggested synchronizing the releases - that may be the way to go if it isnt impractical from an operational point of view.

It'd be nice to get this thought out before dependencies creep in, although I realize it's the wild west out there and all planning goes out the window as time marches on, so maybe not an effective use of time to come up with a grand master plan.

In any case, the goal is to gradually (but consistently!) make more and more Z3 functionality available to Z2 developers in future Z2 releases, based on the most stable Z3 baseline possible.

...

Please correct me if I'm wrong here but I get the sense that Five is less of a "migration path" from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to "straight Z3" will always be more or less a rewrite, no?

It is definitely a migration path. Lets say you have an application based on Z3 with 10 (logical) components. You couldn't feasibly rewrite all of it at once to use Z3. As of 2.8, you'll be able to add functionality to your application using adapters, views, etc. So for V.Next of your app, maybe you are able to port 2 existing components and add 1 new one. For V.Next.Next, you add 2 more and port 2 more. At some point, it *will* be feasible to jump to Z3 with a minmal effort, since you've been able to port your application to components over time.

OK. I still think advertising Five as a migration path is a bit optimistic but I doubt anything would cure skepticism about this other than seeing what you describe actually happen, so only time will tell.

...

...

I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out.

For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;)

Yup... I'm still a bit skeptical but if other folks are committed to maintenance I'd be less so.

Skepticism is healthy, but if it's any consolation, almost everyone involved in this effort has very real 'skin in the game' in terms of existing Zope2 investments. I think that will do a great deal to ensure that the decisions made for future 2.x work are sane and take real-world concerns into account.

Yup I hope so too... - C

Chris McDonough wrote:

Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases.

That will only be an issue when Zope3 has matured so much that new releases do not give people significant benefits to bother upgrading Zope2. ;)

...

But is there and available, so people can begin to plot their own migration paths based on their own situations.

Please correct me if I'm wrong here but I get the sense that Five is less of a "migration path" from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to "straight Z3" will always be more or less a rewrite, no?

Well, what you can do is write Zope2 products that can be easily migrated to zope 3. Is that a migration path? maybe not...

Chris McDonough wrote: [snip]

I assume these caveats are spelled out here because Z3 developers don't want to slow down Z3 development to test/maintain Z2 compatibility. I know a lot about Z2 code, but I know very little about Z3 code. I'd like that to change, but it's likely that I'll just not have the bandwidth to make sure Z3-inside-Z2 works. If that just means I can't use Z3 features but nothing else breaks, it's probably fine, but if Z3 integration actively breaks Z2, it's likely I'll just need for some extended period of time to continue to use and maintain 2.7.

Several of us *do* have the bandwidth to make sure Zope 3 in Zope 2 works, as we're actively using it. Five has been from the start a project that explicitly tried to interfere with both Zope 2 and Zope 3 as little as possible. If you don't use the Zope 3 features in Zope 2, they're just not there.

It'd be great if active Z3 developers could actually help make new releases of Z2 once Five is integrated but the above makes it sound like a "we'll throw it over the wall and you make it work" sort of thing. If it's the latter, maybe as devil's advocate, I need to ask what the point is here?

I think there's a need for active Five developers who do this. Luckily such a group of us exists. We'll make sure Zope 3 in Zope 2 works, Zope 2 developers just focus on Zope 2, and Zope 3 developers focus on Zope 2. We'll try to keep out of your hair as much as possible, and you stay out of our hair, and we'll all cooperate just fine. We've been doing this for over half a year already, after all. As the systems start to merge more in the future, this will get more complicated. But again, Five has been designed to minimize this problem, by carefully being minimally invasive in its Zope 2 integration. We're already using Five with large, complicated systems such as Plone, CPS and Silva, so I think we've been successful.

It appears there is an assumption that merging Z2 and Z3 code within Z2 itself is an unmitigated good thing, but IMHO, each is complicated enough in their own right that I'd personally prefer to be dealing with one or the other at any given time and not both. This isn't exactly idle whining either, I need to do this when I maintain Z4I code, and it's definitely not a walk in the park; it's moderately difficult to do and also difficult find people who have the skills to help too.

Does anyone else share this skepticism or am I about to get shouted down? ;-)

I've already done all this worrying for you and did the right thing with Five, so you're just ignorant. ;) This is a distribution deal more than an integration deal. We're packaging stuff together so we can start using Five more in our projects, and deploy it a lot more easily. Regards, Martijn

Chris McDonough wrote:

On Sat, 2005-03-19 at 12:23, Martijn Faassen wrote:

...

Chris McDonough wrote: [snip]

...

I assume these caveats are spelled out here because Z3 developers don't want to slow down Z3 development to test/maintain Z2 compatibility. I know a lot about Z2 code, but I know very little about Z3 code. I'd like that to change, but it's likely that I'll just not have the bandwidth to make sure Z3-inside-Z2 works. If that just means I can't use Z3 features but nothing else breaks, it's probably fine, but if Z3 integration actively breaks Z2, it's likely I'll just need for some extended period of time to continue to use and maintain 2.7.

Several of us *do* have the bandwidth to make sure Zope 3 in Zope 2 works, as we're actively using it.

Five has been from the start a project that explicitly tried to interfere with both Zope 2 and Zope 3 as little as possible. If you don't use the Zope 3 features in Zope 2, they're just not there.

Great.

I hope you'll forgive the skepticism, it's just that the a lot of the people talking about doing this merge haven't actually checked anything into Zope 2 in a pretty long time, and commit frequency is typically a good indicator (maybe the only indicator) of who might continue to maintain the codebase in the future.

You're right to be skeptical. On the other hand, I haven't seen you commit anything into Five anytime recently. :) Anyway, we need to motivate people to contribute. I've contribued plenty to other projects, not much to Zope, so I started wondering why that might be so. One reason is definitely that a contribution to Zope now may only result in a release of this in the uncertain future, so I have little medium term motivation to contribute. Most of my business motivation is short and medium term, and I believe I share this with many people.

...

...

It appears there is an assumption that merging Z2 and Z3 code within Z2 itself is an unmitigated good thing, but IMHO, each is complicated enough in their own right that I'd personally prefer to be dealing with one or the other at any given time and not both. This isn't exactly idle whining either, I need to do this when I maintain Z4I code, and it's definitely not a walk in the park; it's moderately difficult to do and also difficult find people who have the skills to help too.

Does anyone else share this skepticism or am I about to get shouted down? ;-)

I've already done all this worrying for you and did the right thing with Five, so you're just ignorant. ;)

Right. That's clear. I'm glad you've committed to maintaining it.

Sure, not a problem. I don't know what exactly makes Z4I complicated; I also know Five can be complicated, but the complications are isolated and the developer experience should be easy enough. Regards, Martijn