Hi, I'd just like to know when can we expect a 2.6.1b2. It would be nice to have a new release where we don't have to patch just to get ZClasses to work. -- Ideas don't stay in some minds very long because they don't like solitary confinement.
Hi,
I'd just like to know when can we expect a 2.6.1b2. It would be nice to have a new release where we don't have to patch just to get ZClasses to work.
Yes, it IS indeed a problem if there is no single Zope version out there that can be used without patches. 2.6.0 has the DateTime bug, the 2.6.1b1 has new issues. I have complained a lot about the lousy release management in the past, but nobody seems to listen. Joachim P.S.: After all, it's so easy: Take a Zope version that has some bugs, fix the bugs and release it as a bugfix release. DON'T add features that might trigger new bugs. THEN start working on the next feature release. AND: THERE SHOULD NEVER, I REPEAT: NEVER BE NEW FUNCTIONALITY OR CODE CHANGES BETWEEN A FINAL BETA AND A RELEASE! IF IT IS NOT FINAL; RELEASE ANOTHER BETA!!!!!!
I'd just like to know when can we expect a 2.6.1b2. It would be nice to have a new release where we don't have to patch just to get ZClasses to work.
Yes, it IS indeed a problem if there is no single Zope version out there that can be used without patches. 2.6.0 has the DateTime bug, the 2.6.1b1 has new issues. I have complained a lot about the lousy release management in the past, but nobody seems to listen.
Joachim
P.S.: After all, it's so easy: Take a Zope version that has some bugs, fix the bugs and release it as a bugfix release. DON'T add features that might trigger new bugs. THEN start working on the next feature release.
AND: THERE SHOULD NEVER, I REPEAT: NEVER BE NEW FUNCTIONALITY OR CODE CHANGES BETWEEN A FINAL BETA AND A RELEASE! IF IT IS NOT FINAL; RELEASE ANOTHER BETA!!!!!!
If only it were that easy. Everybody wants "no new features" except for the one feature they desperately want to have without upgrading to the next feature release. :-( --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
If only it were that easy. Everybody wants "no new features" except for the one feature they desperately want to have without upgrading to the next feature release. :-(
Still, we're back to the situation where it's been weeks since the last release, and there's nothing we (the public) can do about that :-( cheers, Chris PS: How's the new zope.org coming?
Guido van Rossum wrote:
If only it were that easy. Everybody wants "no new features" except for the one feature they desperately want to have without upgrading to the next feature release. :-(
Still, we're back to the situation where it's been weeks since the last release, and there's nothing we (the public) can do about that :-(
If you want to make a rogue release, that will be available until Brian deems the time ready for the next release, be my guest.
PS: How's the new zope.org coming?
Very well. I just posted a progress update: http://lists.zope.org/pipermail/zope-web/2003-January/002310.html --Guido van Rossum (home page: http://www.python.org/~guido/)
On Saturday 25 January 2003 1:07 am, Guido van Rossum wrote:
Guido van Rossum wrote:
If only it were that easy. Everybody wants "no new features" except for the one feature they desperately want to have without upgrading to the next feature release. :-(
Still, we're back to the situation where it's been weeks since the last release, and there's nothing we (the public) can do about that
:-(
If you want to make a rogue release, that will be available until Brian deems the time ready for the next release, be my guest.
Is there an estimate for this? afaict, the public schedule since December has been that this is imminent any day now. I have some important bug fixes that I would like to include in 2.6.1, and I would like some assurance that beta 2 will not be released mid-merge. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On Mon, 2003-01-27 at 07:40, Toby Dickenson wrote:
On Saturday 25 January 2003 1:07 am, Guido van Rossum wrote:
Is there an estimate for this?
afaict, the public schedule since December has been that this is imminent any day now. I have some important bug fixes that I would like to include in 2.6.1, and I would like some assurance that beta 2 will not be released mid-merge.
I don't think b2 will be release without a heads-up (right, folks?), so I think you should go ahead and include them, but that's is just MHO. Still, I (and the community, I think) would like to know what's keeping b2 and if there's anything we can do to help it. Maybe this is just another case of a part of the Zope "process" that unecessarily depends on ZopeCorp manpower that could, perhaps, be delegated to the comunity, such as compiling packages for some platforms, etc. -- Ideas don't stay in some minds very long because they don't like solitary confinement.
afaict, the public schedule since December has been that this is imminent any day now. I have some important bug fixes that I would like to include in 2.6.1, and I would like some assurance that beta 2 will not be released mid-merge.
I don't think b2 will be release without a heads-up (right, folks?), so I think you should go ahead and include them, but that's is just MHO.
Still, I (and the community, I think) would like to know what's keeping b2 and if there's anything we can do to help it.
Maybe this is just another case of a part of the Zope "process" that unecessarily depends on ZopeCorp manpower that could, perhaps, be delegated to the comunity, such as compiling packages for some platforms, etc.
Mea culpa - I've not been doing nearly good enough a job at keeping the community informed :( Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them "finalized" has taken longer than I expected. I'll know better later today, but I expect that the fixes will be wrapped up this week, enabling a 2.6.1 b2 next week. Because it has dragged out so long, I'd prefer to get the ZODB fixes in, release 2.6.1 b2 and hopefully soon thereafter a 2.6.1 final with no further changes. A 2.6.2 effort could start as soon after as needed, to add the other fixes mentioned and hopefully also include the fruit of another bug day. Again, sorry about the confusion... Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them "finalized" has taken longer than I expected.
I'd love to know what kind of thing 'large-scale' implies here, and what kind of problems the fixes fixed. -- Steve Alexander
Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them "finalized" has taken longer than I expected.
I'd love to know what kind of thing 'large-scale' implies here, and what kind of problems the fixes fixed.
"Large-scale" meaning large numbers of ZEO clients, that mount multiple ZEO-served databases that are each replicated using ZRS (Zope Corp.'s replication / failover solution) :^) The changes have to do with coordination of transaction commit among multiple databases, manageability and fault-tolerance. I'll ask Jeremy to be sure to update the CHANGES.txt with the important changes. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
"BL" == Brian Lloyd <brian@zope.com> writes:
Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them "finalized" has taken longer than I expected.
I'd love to know what kind of thing 'large-scale' implies here, and what kind of problems the fixes fixed.
BL> "Large-scale" meaning large numbers of ZEO clients, that mount BL> multiple ZEO-served databases that are each replicated using ZRS BL> (Zope Corp.'s replication / failover solution) :^) BL> The changes have to do with coordination of transaction commit BL> among multiple databases, manageability and BL> fault-tolerance. I'll ask Jeremy to be sure to update the BL> CHANGES.txt with the important changes. I've included the current list of changes from ZODB3/NEWS.txt. I believe the list is complete, but would want Barry and Guido to double-check. The first change is possibily controversial. I think the others are fairly conservative. Jeremy The Transaction "hosed" feature is disabled in this release. If a transaction fails during the tpc_finish() it is not possible, in general, to know whether the storage is in a consistent state. For example, a ZEO server may commit the data and then fail before sending confirmation of the commit to the client. If multiple storages are involved in a transaction, the problem is exacerbated: One storage may commit the data while another fails to commit. In previous versions of ZODB, the database would set a global variable "hosed" that prevented any other transaction from committing until an administrator could check the status of the various failed storages and ensure that the database is in a consistent state. This approach favors data consistency over availability. The new approach is to log a panic but continue. In practice, availability seems to be more important than consistency. The failure mode is exceedingly rare in either case. The BTrees-based fsIndex for FileStorage is enabled. This version of the index is faster to load and store via pickle and uses less memory to store keys. We had intended to enable this feature in an earlier release, but failed to actually do it; thus, it's getting enabled as a bug fix now. Two rare bugs were fixed in BTrees conflict resolution. The most probable symptom of the bug would have been a segfault. The bugs were found via synthetic stress tests rather than bug reports. A value-based consistency checker for BTrees was added. See the module BTrees.check for the checker and other utilities for working with BTrees. ZEO --- The ZEO version number was bumped to 2.0.2 on account of the below minor feature additions. The performance of full cache verification has improved dramatically. XXX Get measurements from Jim -- somewhere in 2x-5x recall. The implementation was fixed to use the very-fast getSerial() method on the storage instead of the comparatively slow load(). The ZEO server has an optional timeout feature that will abort a connection that does not commit within a certain amount of time. The timeout works by closing the socket the client is using, causing both client and server to abort the transaction and continue. This is a drastic step, but can be useful to prevent a hung client or other bug from blocking a server indefinitely. If a client was disconnected during a transaction, the tpc_abort() call did not properly reset the internal state about the transaction. The bug caused the next transaction to fail in its tpc_finish().
I updated the Zope 2.6 project page to reflect this, figuring that it should at least be *somewhere* on the web :). <http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/FrontPage> It's nothing fancy, I just included the note and took out some of the older Status notes that reflected the development path towards 2.6.0. On Monday, January 27, 2003, at 11:47 AM, Brian Lloyd wrote:
Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them "finalized" has taken longer than I expected. I'll know better later today, but I expect that the fixes will be wrapped up this week, enabling a 2.6.1 b2 next week.
--On Donnerstag, 23. Januar 2003 20:31 +0100 Joachim Werner <joe@iuveno-net.de> wrote:
Hi,
I'd just like to know when can we expect a 2.6.1b2. It would be nice to have a new release where we don't have to patch just to get ZClasses to work.
Yes, it IS indeed a problem if there is no single Zope version out there that can be used without patches. 2.6.0 has the DateTime bug, the 2.6.1b1 has new issues. I have complained a lot about the lousy release management in the past, but nobody seems to listen.
Joachim
P.S.: After all, it's so easy: Take a Zope version that has some bugs, fix the bugs and release it as a bugfix release. DON'T add features that might trigger new bugs. THEN start working on the next feature release.
AND: THERE SHOULD NEVER, I REPEAT: NEVER BE NEW FUNCTIONALITY OR CODE CHANGES BETWEEN A FINAL BETA AND A RELEASE! IF IT IS NOT FINAL; RELEASE ANOTHER BETA!!!!!!
I think the situation has improved since new features will make it only into the major 2.X.0 releases. All other releases are bugfix releases only. This is at least true for the Zope 2.6 branch were only a minor feature was added to the DateTime module. -aj
participants (10)
-
Andreas Jung -
Brian Lloyd -
Chris Withers -
Guido van Rossum -
Jeffrey P Shell -
jeremy＠zope.com -
Joachim Werner -
Leonardo Rochael Almeida -
Steve Alexander -
Toby Dickenson