-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:

Julien Anguenot wrote:

...

Some Zope3 developers don't care about Zope2 and this is fair enough in my point of view. Zope2 starts to get old and appears to be really a mess compared to Zope3 in *2005*, plus it's not such an attractive platform as it used to be couple of years ago. (Don't get me wrong on this. Time just changed. I'm using Zope2 much more than Zope3 nowadays and still I like it even if I'm *dreaming* about only using a modern platform "à la" Zope3) I would fear that some new folks might find the Zope3 project much more confusing and less attractive because of the Zope2 mess around. (common mailing list, common repository etc...)

Please, let's not mess up Zope3...

[...]

You state correctly that "some Zope 3 developers don't care about Zope2". This might seem like a suitable point of view, but as Martijn pointed out very well, it's also a foolish one. It limits the acceptance of Zope 3 within the Zope community.

And what about the acceptance of Zope3 *outside* the Zope community ? Zope3 will look like more complicated and confusing doing a merge. I'm more concerned about the acceptance of Zope3 outside the Zope community because Zope2 developers will have to move to Zope3 at a certain time. It's juste much more easier than for the first people.

Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to re-embrace it, though. In fact, the idea of this proposal is not that Zope 2 is going to stay with us forever. It is about speeding up the convergence process!

I understand your motivations Philipp. I just think this is too early. When Zope2 will look like a Zope3 'configuration' then maybe it could be of interest.

There are a good amount of people, Martijn and me included, who are working towards improving Zope 2 and we simply want to attract more people to help us.

I still believe Zope2 developers will come on Zope3 pretty easily. The challenge is people outside the Zope community and I'm more worried about them.

Zope 2's architecture might be shitty, but its community is bigger, don't forget that.

I never said shitty. Take it easy on the interpretation. I'm using Zope2 for years and it's with what I'm working daily. I said *old* and it's different. It's not as attractive as it used to be couple of years ago. This is a fact. This is why Zope3 exists. I still believe your proposal would be a mistake at this point for Zope3. Cheers, J. - -- Julien Anguenot | Nuxeo R&D (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDhTLOGhoG8MxZ/pIRAmSwAJ0e8d2S/lyXgeTm3dAQgqBh50eJzwCeONEC 52QuaUKLeFESP+Ytar3NkDE= =bc5x -----END PGP SIGNATURE-----

On Thu, 2005-11-24 at 04:56 +0100, Philipp von Weitershausen wrote:

I think Martin Aspeli is not the only one who still has no clue on how to move forward beyond a certain Fivization of his Zope 2 products. If you do, then that's great, but I don't think everyone is in that fortunate situation.

I really, really appreciate Phil taking the time to propose this no matter what happens. But I don't have much of a dog in this fight either way. If the SVN merge happened, that'd be ok with me; if it didn't, that'd be ok too. I'd personally be more likely to contribute to Z3 if it did happen, but given the extent of my recent contributions to Z2 (minimal lately), that may not be such a win for anybody. So I'm +0 on the idea. If it did happen, I'd do my best to help solve Five test failures caused by reasonable Z3 changes. All that said, because I think it may be valuable to somebody, I'll try to provide a perspective about convergence from someone who: - Is a long-time Z2 developer. - Works with Z2 more or less exclusively. - Does more paid work than volunteer work on Z2. (e.g. it's largely just business now, not a passion). This will be pretty long. ;-) As opposed to about 8 months ago, I'm not in a position anymore where I have zero clue about Zope 3. That said, any cluefulness that I have about Zope 3 stuff has come largely as a result of using Five for customer projects. So I'm still pretty clueless about huge swathes of Z3. I'd of course like to be less clueless. I do most of my learning "on the job", so in order to really begin to use Z3 in anger, I'll need to use it for paid work. But it's unlikely that I can port *existing* Z2 customer projects over to "pure" Zope 3 if only because I really can't ethically charge someone to do that, nor do people really want to pay for it even if I could. It's great to be able to use Five to gradually use Z3 things but they'll never be "Z3-only" apps. They work just fine now under Z2 and will for a few more years at least. There's just no reason to port them. Of course it's possible that some future customer apps will be Z3 apps. That said, most of the work I get these days is in one of the following categories: - We have a slow Zope 2 application, please make it faster. - We are Zope 2 developers and we need some help on a specific piece of a project. These projects are often not good Z3 candidates for the same "don't fix it if it aint broke" reasons I mention above about existing customer projects. However, when "new" work comes in where it's simply in the form of a set of requirements rather than an already-running code base, I can of course choose to use Z3. These kinds of opportunities have presented themselves a few times in the last year or so. But I have to admit that each time one has, I've decided to stick with Z2 because not doing so would mean reimplementing (or at least porting) a lot of stuff that I know already exists for Z2 but which either has no Z3 analogue or at least has no Z3 analogue that I could personally vouch for without doing a lot of research. It's not really *major* stuff... cache managers, database adapters, transactional mail host tools, active directory connectors, heavy production sessioning requirements, blah blah blah. Any one of which could probably be researched in a day and coded up in less than another day. But it's a day and a half that I'd need to bill the customer for. Those days add up. And I like getting repeat business, so I try to keep customers happy by not taking them down ideological rabbit holes. Of course, there's a market bias here. I get more Z2 work because I've been doing Z2 work for a long time. I'm also currently much more valuable as a Z2 developer for the same reason. as As a Z3 book author, Stephan likely gets offers for work involving Z3 more than he does for work involving Z2. So it's easy to get tunnel-vision on both sides. Some observations that may be due to tunnel-vision that lead me away from developing "pure" Z3 apps: - There doesn't seem to be as much of a commitment in the Z3 community to backwards compatibility as there is for Z2. Notes like Stephan's last one where he says "I have made deep changes in the past that affect the entire architecture" as if this may happen again at any time are pretty scary. It seems to imply that Z3 is still in an alpha phase. I know *the software* isn't but if this sort of deep changes are still deemed necessary, the design appears to be, which makes it almost completely uninteresting to use for production systems. Z2, for all its other failings, makes deep commitments about backwards compatibility. This shackles it in many respects but it also makes it an attractive development platform for people who are concerned about just getting the job done and having their software work over a long period of time across major releases. - Z3 has naive or non-battle-tested implementations of key services. Sessioning appears to be super-naive in Z3 (I'm not absolved of this fact, I know). Some database adapters seem like they're just promises of an actual database adapter. It's not as if these services' implementations aren't elegant or as if they're ugly or something, it's just usually that they're broken-in-the-real-world-outside- of-the-test-runner-in-some-slight-way. The first point I think can only be solved by providing a clear committment to backwards compatibility; deprecations are OK, but give folks time to fix the code before you yank out the rug, and so on. I think this commitment already exists but I can't really be sure given some of the language being tossed around here lately by Stephan. The second I think as a Z2 developer I could help Z3 out with. There are many more Z2 servers in production than there are pure Z3 servers. Lots of lessons have been learned by Zope 2 and Plone folks revolving around actual, real, honest-to-god, needs-to-run-today-and-I'm-not-joking operations and production issues. Existing Z2 developers could help bring solutions into Z3 that they've already performed for Z2 here. (Sometimes code that appears unclean is that way *because* it actually works, not in spite of it. ;-) In summary: I think it would be helpful to treat Z3 as a stable product which means trying to resist dreams of ripping it all apart again and redesigning it in fundamental backwards-incompatible ways in order to make it cleaner. It could also use some TLC from a larger developer base who has a broader range of operational requirements. Anyway, just some observations from a casual user. I'm sure I'll get toasted for something I said here because I'm sure there are inaccuracies and whatnot above this but it probably can't be helped. ;-) I've already spent more time writing this mail than I actually feel like I have to spend on the subject.

...

I never said shitty. Take it easy on the interpretation.

Yes, yes. You know how to interpret "shitty" very well... old, worn-out, inflated, etc... Seriously, when everyone gives gigakudos to Florent and offers him 10 gallons of beer for looking through Zope 2 security code, I think at least the maintainability of some of the Zope 2 code is shitty, or at least perceived to be shitty.

I think "without automated tests" is the definition of shitty. Anyone who changes old Bobo-era Zope code either writes missing tests or at least begins to "own" the code to some extent. The code itself is not uniformly awful, some of it is actually quite good, but the fact that in order to go in to make a simple change, you become responsible for either writing a comprehensive suite of tests for some component or become the code's owner (or both) is what makes the situation unpleasant. Z3 is much better in this respect because the test coverage is better. The code might still be spotty, but the tests catch it. - C

On Thursday 24 November 2005 01:39, Chris McDonough wrote:

- There doesn't seem to be as much of a commitment in the   Z3 community to backwards compatibility as   there is for Z2.  Notes like Stephan's last one where   he says "I have made deep changes in the past that affect   the entire architecture" as if this may happen again at   any time are pretty scary.

Except that I have provided full backward-compatibility. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

Julien Anguenot wrote: [snip]

And what about the acceptance of Zope3 *outside* the Zope community ? Zope3 will look like more complicated and confusing doing a merge.

People building on Zope 3 will presumably mostly be working with a Zope 3 release, which will not include Zope 2. So, they cannot be confused by Zope 2 in that way. But if they're to become Zope 3 core developers they'll have to learn about this, yes.

I'm more concerned about the acceptance of Zope3 outside the Zope community because Zope2 developers will have to move to Zope3 at a certain time. It's juste much more easier than for the first people.

[snip]

I still believe Zope2 developers will come on Zope3 pretty easily.

I don't think it is easy at all. While any competent Zope 2 developer will be able to learn about Zope 3, there's also the question of motivation and opportunity to do so. Only thanks to Five is the Plone community making any move to Zope 3 at all, for instance. There's a pretty huge barrier between Zope 2 and Zope 3 and only recently has it been slowly coming down in the minds of Zope 2 developers. While I don't doubt developers will be coming to Zope 3 from outside the Zope community, I also think that by far the biggest amount of developers will be coming from *within* the Zope community, and if we want to gain more developers for Zope 3, *that* is the best place to look. It's our community, let's take care of it.

The challenge is people outside the Zope community and I'm more worried about them.

Outside the Zope community Zope 3 doesn't have such a great image indeed. It's either ignored, or it's actively rejected. There is a lot of competition with other frameworks. Zope 3 is currently not doing particularly well in this competition, something we need to fix, but that's another topic for another thread. It doesn't change that inviting in the Zope 2 developers is most effective thing we can do at present to grow the Zope 3 community. Regards, Martijn

Hi [...]

Martijn Faassen wrote:

...

... Outside the Zope community Zope 3 doesn't have such a great image indeed. It's either ignored, or it's actively rejected. There is a lot of competition with other frameworks. Zope 3 is currently not doing particularly well in this competition, something we need to fix, but that's another topic for another thread. It doesn't change that inviting in the Zope 2 developers is most effective thing we can do at present to grow the Zope 3 community.

Regards,

Martijn

Hi,

It is a bit like this: the zope2 community wants the zope3 technology and zope3 wants the zope2 community.

I think the question about the technology should be treated as such on a technical level, by bridging the technical gap (Five, common repositories, writing tutorials for zope2 developers, collaborating on common modules, adapting zope2 concepts like TTW editing to Zope3 but without reproducing the zope2 skin and templates mess, etc).

But the question about the communities involves more complicated aspects, i.e. marketing issues, licenses, competition, strategies, etc. The repository is not the answer. This has to be solved on a higher level, Zope Foundation, updated ZPL license, ... where a social contract is agreed on.

So let's not pretend that everything can be solved on a technological level even though lots of it can ..

+1 for that Regards Roger Ineichen

Regards /JM _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch

Martijn Faassen wrote:

Jean-Marc Orliaguet wrote: [snip]

...

It is a bit like this: the zope2 community wants the zope3 technology and zope3 wants the zope2 community.

I like this analysis. :)

...

I think the question about the technology should be treated as such on a technical level, by bridging the technical gap (Five, common repositories, writing tutorials for zope2 developers, collaborating on common modules, adapting zope2 concepts like TTW editing to Zope3 but without reproducing the zope2 skin and templates mess, etc).

But the question about the communities involves more complicated aspects, i.e. marketing issues, licenses, competition, strategies, etc. The repository is not the answer. This has to be solved on a higher level, Zope Foundation, updated ZPL license, ... where a social contract is agreed on.

Be careful with what you're implying with words: marketing aspects more complicated than code, "higher level", etc. I don't necessarily agree with the underlying assumptions.

While I fully support efforts surrounding the Zope Foundation, I really think that this is not the right level to solve community issues. A Foundation can make social contracts all they like, for instance, but if people in the community don't follow them, nothing will happen.

Marketing issues and strategies are frequently happening a bit more subtly than you seem to say here. The difference between the "technical" and the "community" level is far less clear than you make it seem.

Five, for instance, is *not* just a technical project. It never has been. Five is a community project at least as much, to change people's *minds*, to merge communities, to change the shape of the Zope business, as much as it's to make technical changes. That's why there's talks given about conferences, for instance. These things go hand in hand.

Merging the repositories is also not just technical. It's clear enough that it's not -- the discussion in this thread is not about technical issues *at all*. They're about impact on the people involved in Zope 2 and Zope 3 development.

...

So let's not pretend that everything can be solved on a technological level even though lots of it can ..

We're in open source. Our solutions are frequently technological *and* community-based. That's the point of open source. Let's not artificially separate the two issues.

Regards,

Martijn

Hi Martijn, I think you're mixing the notions of "community" and of "community of interests". I don't think that the goal is to merge communities, the goal is to make good software and not have different entities fight on framework technologies. It is to stir common *interests* in the technology. On the technical level CMF is used by many, but still different communities. Five is a community project used by different communities. This also shows that technology merge does not entail community merge, because everyone comes with different goals, backgrounds, and this is sound. Python is a community project, not everyone who uses python is in the same community (reads the same mailing-lists, go to the same conferences, develop with zope or twisted, ) even though there is a strong community of interests. I think that you want technology merge in the first place, and not force people into communities through technology. Regards, /JM

Martijn Faassen wrote:

Jean-Marc Orliaguet wrote: [snip]

...

I think you're mixing the notions of "community" and of "community of interests".

I don't think that the goal is to merge communities, the goal is to make good software and not have different entities fight on framework technologies. It is to stir common *interests* in the technology.

On the technical level CMF is used by many, but still different communities. Five is a community project used by different communities. This also shows that technology merge does not entail community merge, because everyone comes with different goals, backgrounds, and this is sound.

Python is a community project, not everyone who uses python is in the same community (reads the same mailing-lists, go to the same conferences, develop with zope or twisted, ) even though there is a strong community of interests.

I think that you want technology merge in the first place, and not force people into communities through technology.

How do you know what I want?

That's an expression. I don't mean "you" in particular. It's like saying "people" want to, "one" wants to, "you want to" ...

I indeed do not understand your point. I'm not sure you understand mine, as you seem to be partially telling me things I already understand, and partially arguing with things that aren't my position.

Regards,

Martijn

I don't think it's very important; it was just a point of view that I was expressing for the sake of the analysis trying to separate community issues from technological issues (trying to not put everything in the same bag). But sure, if every technology is to be considered as a social project with the goal to change people's mind, then there is no reason to make any difference between the two. I think you're giving to the word "technology" more meaning than I do. Regards /JM

Stephan Richter wrote:

On Wednesday 23 November 2005 22:01, Philipp von Weitershausen wrote:

...

Messing up Zope 3 is specifically not the intention of this proposal. It says so explicitly in the "Your questions answered" section.

Though it is not your intend, the merge would in fact mess up the trunk, specifically from a Zope 3 developer's perspective.

Really, *how* does it mess up the trunk? Half of the packages of Zope 2 are also in Zope 3 because they're either ZODB or Zope3-related anyway. Another quarter of the packages will go away within one year, I think (such as DocumentTemplate, StructuredText, etc., as they are duplicate implementations of zope.documenttemplate, zope.structuredtext, etc.).

...

You state correctly that "some Zope 3 developers don't care about Zope2". This might seem like a suitable point of view, but as Martijn pointed out very well, it's also a foolish one. It limits the acceptance of Zope 3 within the Zope community.

How is it foolish? I have no need for Zope 2, so why should I maintain it?

No one is asking you to maintain it. You're confusing maintance with bringing up to speed with refactorings.

There is nothing in for me here.

That I doubt. There's a lot of code and experience in the Zope 2 community which might be underestimated...

...

Zope 2 is a mess, I give you that. I'm not asking any Zope 3 developer to re-embrace it, though.

But I have to relearn it for the pure purpose of developing on the Zope 3 trunk. That's just not right!

No one says you have relearn Zope 2; you merely have to run the tests. See my other post about this.

...

In fact, the idea of this proposal is not that Zope 2 is going to stay with us forever. It is about speeding up the convergence process! There are a good amount of people, Martijn and me included, who are working towards improving Zope 2 and we simply want to attract more people to help us.

Yeah, you are forcing me to help you out!

So are you with zope.wfmc, zope.contentprovider, zope.viewlet and all those other things that you and others checked into Zope 3 and I have no clue about whatsoever. Sorry, this argument is moot because not too long ago the Zope 3 repository was strongly advertised as a place for people to put their Zope3-related software so that it would be kept up to speed with refactorings and such. If that offer was for non-Zope-core software, it should especially be good for Zope itself.

...

The few "Zope 3 developers [that] don't care about Zope2" are the minority and I think they could use the help from the rest of the Zope community.

It depends on the perspective you take. If you look at the whole community, then yes, we are probably in the minority (even though that counting all people that voted so far, there are more -1 votes). A more appropriate sample would be the people actually contributing to Zope 3 on a regular basis or the ones that exclusively use Zope 3. Using this group, we have about an 80-90% -1 vote count.

Sure, I realize that. Note however that I'm looking to get more Zope 3 contributors with this action. As I've pointed out before, I treat a +1 from an active Zope 2 developer as a commitment towards Zope 3 contributions. Even pure Zope 3 developers will benefit from that because it takes work off their shoulders. Philipp ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

On Thursday 24 November 2005 00:57, Benji York wrote:

...

not too long ago the Zope 3 repository was strongly advertised as a place for people to put their Zope3-related software so that it would be kept up to speed with refactorings and such. If that offer was for non-Zope-core software, it should especially be good for Zope itself.

I think the time has come for this to change.  With a maturing code base and with systems like BuildBot we should be able to assure cross project testing (between Zope 2, Zope 3, and non-core projects).

Right, Jim's main motivation for getting buildbot set up was so that we could do cross-project testing. Zope3/ should no longer be seen as a dumping place for add-on packages, including zwiki and bugtracker. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training

On 11/23/05, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:

Using this group, we have about an 80-90% -1 vote count.

I'll weigh in with a -1 as well, for all the reasons cited by the other -1 voters on this issue. Zope 2 and Zope 3 are far too different at this point. The only way I see for convergence to be a good thing is for Zope 2 to be essentially skin and configuration on top of Zope 3; I really don't want to end up with Zope 2. Jim's vision is strongly for convergence, and I'm sure he'll say that himself when he's back (he's away for a few days). I don't pretend to know what he'll say about this idea, though. I don't *think* he think's it's time, but he doesn't like people predicting what he'll say. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "There is no wealth but life." --John Ruskin