Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
--On Freitag, 18. März 2005 12:31 Uhr -0500 Jim Fulton [EMAIL PROTECTED] 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? Andreas pgpxff4mmemuu.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope on Windows - REQUEST for volunteers
Hi, there are several open issues in the Zope collector with Zope running on Windows. I can't see anyone worrying about the Windows platform (I also don't care about Windows as UN*X guy). So if you are interested in running Zope on Windows in a reasonable way than *you* should help to fix the outstanding bugs. I heard some remarks (behind my back) that Zope is not a stable solution on Windows...possibly.but since Zope is a community-driven project people doing such remarks should either shut up or help to improve the situation by volunteering (which is also true for other parts of the Zope development). So if you want to improve running Zope on Windows: go the Zope collector, search for Windows related problems, find a solution, submit a patch and don't expect that everything can be handled by the handful of active Zope 2 core developers...means it's also up to *YOU*. Andreas pgpzyLj6pwyY5.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: --On Freitag, 18. März 2005 12:31 Uhr -0500 Jim Fulton [EMAIL PROTECTED] 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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Brian Lloyd wrote: Hi all, There have been a number of threads going on today re: Zope X3.1 feature freeze and the 2.8 effort. I'd like to clarify some decisions re: Zope 2.8 Jim is the product mgr for Zope 3 and I'm it for Zope 2, so hopefully this can be considered authoritative and end part of this thread ;) Absolutely - Zope 2.8 will include X3.0 (not X3.1) - The Z3 developers will have *no* extra burden or responsibility to support X3.0 beyond what they would normally do in the normal course of maintaining it for Z3-only applications. In other words, it is not the responsibility of Z3 devs to make sure Z2 tests pass, etc. I think this is a reasonable compromise. ... - As a community, we will work out how best to adapt the Zope 2 release process and schedule to that of Zope 3 going forward. We don't need to decide this immediately to continue to make progress on 2.8. I suggest an IRC meeting sometime soon to draft a proposal. I would like to see the Zope 2, Zope 3, and ZODB release cycles combined, at least for feature (dot zero) releases, starting with Zope 2.9 and X3.2. That is, I'd like them to have the same release cycle. These should, of course, be time-based releases. My preference is for every 6 months, but I'm more than willing to try 4. My worry is that if the cycles are too short, there will be inadequate time for alpha and beta releases. Plus, a 6-month cycle would allow us to say that deprecated features will be supported for a year. (Of course, we could do that anyway if we supported 3 releases instead of 2.) Thanks Brian! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: [snip] 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. Are optimizations a feature? I guess so. :) 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. Alpha 2 is fine with me, and I think most people of the sprint agreed. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Clarification re: Zope X3.1, 2.8
Andreas Jung wrote: [snip] 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. [snip] 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). I think it does matter that we're not creating new code, but loosely integrating code that already exists, used, and, mostly, has already been released. I think that's quite different from what you describe was a problem with the Plone 2.0 release. No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed. [snip] 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'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. 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. 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 would also like to refer you to the Linux kernel, where release candidates are rarely tested, and the real bugs come out with production releases. I think that's also a reality for Zope. The core Plone, Silva and CPS developers present at the sprint also expressed a strong preference for getting this into production quickly. There will be bugs in Zope 2.8, but a Zope 2.8.1 release should be relatively easily made if that's the case. There are some resources available to make this release happen on time. I'll commit a bit of my time, and I trust the others who worked on this at the sprint will chip in as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope3-dev] Clarification re: Zope X3.1, 2.8
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RE: Clarification re: Zope X3.1, 2.8
Chris McDonough wrote: [snip] 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 will be far *less* of a rewrite. Evolution is not easy, but we have had some success at the sprint at converting Five-based code to pure Zope 3 based code, and vice versa. Five is very much intended to be a migration path. Once you are using views and adapters, schema and forms, and so on, in your code, and slowly move your existing code to use these technologies, porting the code over to straight Zope 3 will be more and more easy. Muc of Five ZCML just literally works in Zope 3; the views work virtually the same, for instance. Evolution, not revolution. [snip] 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. I'll repeat that I'm committed to this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Cookie problem with mySqlUserFolder
Aruna Kathiria wrote at 2005-3-18 16:22 -0800: ... I checked what problem would be and found that each time logged in process on different computers generates a random value for cookie on that computer and also store same value in Tokens table on mysqlUserFolder database. So everytime only cookie from one computer matches the value with Tokens tables value. So other computer don't remember the previous login. ( Though I don't know this is the reason of my problem) What would be the solution to keep reorganization on all computers on which once user has been logged in? Any help will be appreciated. Looks like you have to change mysqlUserFolder to not generate a random number but reuse that from an ealier connect from a different computer... You might open a security hole by doing so... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Zope on Windows - REQUEST for volunteers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: | Hi, | | there are several open issues in the Zope collector with Zope running | on Windows. I can't see anyone worrying about the Windows platform (I | also don't care about Windows as UN*X guy). So if you are interested | in running Zope on Windows in a reasonable way than *you* should help | to fix the outstanding bugs. I heard some remarks (behind my back) | that Zope is not a stable solution on Windows...possibly.but | since Zope is a community-driven project people doing such remarks | should either shut up or help to improve the situation by | volunteering (which is also true for other parts of the Zope | development). So if you want to improve running Zope on Windows: go | the Zope collector, search for Windows related problems, find a | solution, submit a patch and don't expect that everything can be | handled by the handful of active Zope 2 core developers...means it's | also up to *YOU*. I told Alan Runyan at the sprint in Paris that we would be glad to have Enfold's Windows stability patches folded back into upstream. He was glad to hear it; I hope to see something from Andy / Alan / Sidnei soon. I'd really like to see our win32all story cleaned up, per Mark Hammond's issues, too. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCPNAQGqWXf00rNCgRAkrFAKCFAwftLGixrzPhcDHYkihm+Je76wCcC51t 21WeJPU6M0IlgKvv2UUMilI= =Yw3l -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
