The DateTime bug in 2.6.0 breaks all of my sites. This must be true for very many other people. If we collectively want use of Zope to multiply 10x, I don't think it's a great idea to let a major bug like that stay in the latest-and-greatest release. Can we have a bugfix release? seb ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites -aj --On Mittwoch, 27. November 2002 11:18 +0000 seb bacon <seb@jamkit.com> wrote:
The DateTime bug in 2.6.0 breaks all of my sites. This must be true for very many other people.
If we collectively want use of Zope to multiply 10x, I don't think it's a great idea to let a major bug like that stay in the latest-and-greatest release.
Can we have a bugfix release?
seb
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
--------------------------------------------------------------------- - Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - - "Life is too short to (re)write parsers" - ---------------------------------------------------------------------
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
That really doesn't matter. The official release on http://www.zope.org/Products still has the bug. -- /Magnus
Andreas Jung <lists@andreas-jung.com>:
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
You miss my point. It may have a trivial fix, but this is a severe bug which should not be in released software. What is the argument *agains* a bugfix release, exactly? Seb
--On Mittwoch, 27. November 2002 11:18 +0000 seb bacon <seb@jamkit.com> wrote:
The DateTime bug in 2.6.0 breaks all of my sites. This must be true for very many other people.
If we collectively want use of Zope to multiply 10x, I don't think it's a great idea to let a major bug like that stay in the latest-and-greatest release.
Can we have a bugfix release?
seb
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
--------------------------------------------------------------------- - Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - - "Life is too short to (re)write parsers" - ---------------------------------------------------------------------
------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
Andreas Jung wrote:
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
I'll echo my earlier comment: Whatever happened to "release early, release often"? Why is this not happening with Zope? cheers, Chris
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
I'll echo my earlier comment: Whatever happened to "release early, release often"?
Why is this not happening with Zope?
Because it doesn't apply. "Release early, release often" is for bleeding edge developers. For a system like the Linux kernel, where it's nearly impossible to check out a consistent version from CVS, daily or weekly snapshot releases are a good idea. With Zope, bleeding edge developers have access to CVS, so there's no need for such "releases". A bugfix release for Zope 2.6.0, named Zope 2.6.1, was planned for this week. But yesterday, three new bugs in 2.6.0 were reported, and we'd like to fix those too. With the holidays, it'll be next week. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Why is this not happening with Zope?
Because it doesn't apply. "Release early, release often" is for bleeding edge developers.
Says who? I thought the idea behind it was to get the releases out early, so you can find the bugs faster and get the releases more stable more quickly... I guess what I'm saying is that for a version 2.x.y, x should behave as you describe while y should go up as often as a bug is discovered and fixed... cheers, Chris
Says who? I thought the idea behind it was to get the releases out early, so you can find the bugs faster and get the releases more stable more quickly...
I guess what I'm saying is that for a version 2.x.y, x should behave as you describe while y should go up as often as a bug is discovered and fixed...
That means we either waste a lot more time doing releases, or the releases become a lot more shoddy, hardly more than a snapshot from CVS. Neither sounds attractive, sorry. --Guido van Rossum (home page: http://www.python.org/~guido/)
I guess what I'm saying is that for a version 2.x.y, x should behave as you describe while y should go up as often as a bug is discovered and fixed...
That means we either waste a lot more time doing releases, or the releases become a lot more shoddy, hardly more than a snapshot from CVS. Neither sounds attractive, sorry.
Right. So what we really should do instead, is this http://www.python.org/peps/pep-0251.html The important parts, imho: * "Small bug fixes and changes will occur up until the first beta release." * "A week before every alpha, beta or other release, we forked off a branch which became the release. Changes to the branch are limited to the release manager and his designated 'bots." Thats really the current problem. Changes happening just before the release. -- /Magnus
Guido van Rossum wrote:
That means we either waste a lot more time doing releases, or the releases become a lot more shoddy, hardly more than a snapshot from CVS. Neither sounds attractive, sorry.
...or the release process becomes automated/documented enough that neither of these happen ;-) Chris
From: "Andreas Jung" <lists@andreas-jung.com>
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
Yep, it's on http://www.zope.org/Members/regebro/ somewhere. But I agree that it's time for a bugfix release pretty soon. Most serious bugs should have appeared by now, and making a bug fix release shouldn't be that hard, or?
From: "Andreas Jung" <lists@andreas-jung.com>
Someone posted already a fix for this problem. It should not be hard to fix this single problem by exchanging the DateTime.py file on your sites
Yep, it's on http://www.zope.org/Members/regebro/ somewhere. But I agree that it's time for a bugfix release pretty soon. Most serious bugs should have appeared by now, and making a bug fix release shouldn't be that hard, or?
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta. Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Wednesday 27 November 2002 5:50 pm, Brian Lloyd wrote:
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta.
Im not sure this is a good plan. Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow. Sure,
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta.
Im not sure this is a good plan.
Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow.
My understanding was that objects would not be required to implement sortKey (and wouldn't be adversely affected for not implementing it) unless they cared about the specific issue that it addresses. I'll verify this w/Jeremy tomorrow, but last I heard ordering should only actually be an issue for Connection objects - other objects that play with the transaction mgr will generally not be subject to the deadlock issue that the sorting is designed to prevent (the deadlock is due to connection interaction w/a storage server). Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Sunday 01 December 2002 3:36 pm, Brian Lloyd wrote:
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta.
Im not sure this is a good plan.
Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow.
My understanding was that objects would not be required to implement sortKey (and wouldn't be adversely affected for not implementing it) unless they cared about the specific issue that it addresses. I'll verify this w/Jeremy tomorrow, but last I heard ordering should only actually be an issue for Connection objects - other objects that play with the transaction mgr will generally not be subject to the deadlock issue that the sorting is designed to prevent (the deadlock is due to connection interaction w/a storage server).
Yes, Jeremys changes should be entirely backwards compatible. I have commented on zodb-dev how well this has been handled. I am entirely confident that it can go into a 2.6.x fairly soon. However it is still a major change to a critical component, with some indications that things are not 100% right: http://collector.zope.org/Zope/701 http://lists.zope.org/pipermail/zodb-dev/2002-November/003810.html I am not normally shy of the bleeding edge, but I am still running the cvs dated 2002-11-11 in production. This one change makes me nervous. A bug in the transaction manager would be really bad news. I would have thought it appropriate to resolve these problems and leave at least a few weeks of beta test before release.
"TD" == Toby Dickenson <tdickenson@geminidataloggers.com> writes:
TD> A bug in the transaction manager would be really bad news. I TD> would have thought it appropriate to resolve these problems and TD> leave at least a few weeks of beta test before release. I'm looking into the problem, as I reported on zodb-dev. Recall that we're talking about releasing Zope 2.6.1 beta 1 -- a beta maintenance release. I'm not sure how much testing Brian would like to see before a final release of 2.6.1, but "a few weeks" seems like the right order of magnitude. Jeremy
On Fri, 29 Nov 2002, Toby Dickenson wrote:
On Wednesday 27 November 2002 5:50 pm, Brian Lloyd wrote:
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta.
Im not sure this is a good plan.
Jeremy's sortKey changes look like they deserve a longer beta testing period than I would have thought the demand for a DateTime fix would allow.
This whole discussion makes it sound like a more automated release process would be a very very helpful goal as far as supporting the community-supported nature of zope. If such a thing existed, we could have easily followed ChrisW's suggestion and rolled a 2.6.1 release with just the DateTime bug fixed. It seems to me that is an important capability to have, especially if we want to start doing "security" fixes as dot releases instead of as hot fixes. --RDM
Brian Lloyd wrote:
FYI I'd like to have a 2.6.1 beta out next week. Jeremy is still looking at a few ZODB bug reports - as soon as he's done we'll make the beta.
HelpSys DTML Reference node is broken. Please consider at least a two line bugfix for 2.6.1. - if id[:5]=='dtml-': + if id[:5].lower()=='dtml-': dtmltopics.append(topic) - if (id[:5] in ('metal', 'tales') and id[5] in ('.', '-')) or \ + elif (id[:5] in ('metal', 'tales') and id[5] in ('.', '-')) or \ (id[:3]=='tal' and id[3] in ('.', '-')): zpttopics.append(topic) else: topics.append(topic) I uploaded a bigger patch to <http://collector.zope.org/Zope/704>, that also takes care of other nodes. Please let me know if it's ok to checkin the patch or at least the 2 line fix to branch and/or trunk. Cheers, Yuppie
Yuppie wrote:
HelpSys DTML Reference node is broken. Please consider at least a two line bugfix for 2.6.1.
- if id[:5]=='dtml-': + if id[:5].lower()=='dtml-': dtmltopics.append(topic) - if (id[:5] in ('metal', 'tales') and id[5] in ('.', '-')) or \ + elif (id[:5] in ('metal', 'tales') and id[5] in ('.', '-')) or \ (id[:3]=='tal' and id[3] in ('.', '-')): zpttopics.append(topic) else: topics.append(topic)
I have to cut back on my request: The first point could be intended: Uppercase DTML help is used for DTML Document and DTML Method help. So really buggy is only the 'if' instead of 'elif'. This makes DTML Reference show up twice. See also <http://collector.zope.org/Zope/704> . Cheers, Yuppie
On 27 Nov 2002, 11:18 seb bacon wrote:
Can we have a bugfix release?
Me too. I'd like to get the fix for Issue 597 (http://collector.zope.org/Zope/597) in such a bugfix release. ZCTextIndex, quite different from the old TextIndex, currently is almost unusuable outside the US, because it isn't locale aware. A fix was posted to the collector during the 2.6 beta period, about two weeks BEFORE (!) the release of 2.6.0, by Maik Jablonski, but has been ignored, since.. It's still not checked in, if I'm not mistaken. :-( What is beta testing good, if the error reports get ignored? Why write patches, if those patches are thrown away?
On Wed, 2002-11-27 at 12:31, Wolfgang Strobl wrote:
On 27 Nov 2002, 11:18 seb bacon wrote:
Can we have a bugfix release?
Me too. I'd like to get the fix for Issue 597 (http://collector.zope.org/Zope/597) in such a bugfix release. ZCTextIndex, quite different from the old TextIndex, currently is almost unusuable outside the US, because it isn't locale aware.
A fix was posted to the collector during the 2.6 beta period, about two weeks BEFORE (!) the release of 2.6.0, by Maik Jablonski, but has been ignored, since.. It's still not checked in, if I'm not mistaken. :-(
What is beta testing good, if the error reports get ignored? Why write patches, if those patches are thrown away?
I understand your frustration. It may be a good idea to bug a developer with CVS commit access that you know cares about the issue. Sometimes going through the CVS logs for the module in which the bug is in, you can tell who has most recently been involved in that code and send them an email about the bug. The collector is tended to on an as-possible basis. We haven't had a "bug day" lately so it's not surprising that there is stuff in there that hasn't been vetted and merged. By emailing a developer personally, you run the risk of bugging them, but the worst they can say is no. To avoid this entirely, know that anyone can apply (although possibly not obtain) CVS checkin access to Zope. See http://dev.zope.org/CVS/WriteAccessRationale . Having a bug that you care about deeply might be a good enough reason to apply. Thanks, - C
--On Mittwoch, 27. November 2002 13:17 -0500 Chris McDonough <chrism@zope.com> wrote:
On Wed, 2002-11-27 at 12:31, Wolfgang Strobl wrote:
On 27 Nov 2002, 11:18 seb bacon wrote:
Can we have a bugfix release?
Me too. I'd like to get the fix for Issue 597 (http://collector.zope.org/Zope/597) in such a bugfix release. ZCTextIndex, quite different from the old TextIndex, currently is almost unusuable outside the US, because it isn't locale aware.
A fix was posted to the collector during the 2.6 beta period, about two weeks BEFORE (!) the release of 2.6.0, by Maik Jablonski, but has been ignored, since.. It's still not checked in, if I'm not mistaken. :-(
What is beta testing good, if the error reports get ignored? Why write patches, if those patches are thrown away?
I understand your frustration. It may be a good idea to bug a developer with CVS commit access that you know cares about the issue. Sometimes going through the CVS logs for the module in which the bug is in, you can tell who has most recently been involved in that code and send them an email about the bug.
Especially for this bug there are additional unittests missing to check the locale-wareness of the patches. -aj --------------------------------------------------------------------- - Andreas Jung http://www.andreas-jung.com - - EMail: andreas at andreas-jung.com - - "Life is too short to (re)write parsers" - ---------------------------------------------------------------------
From: "Chris McDonough" <chrism@zope.com>
Sometimes going through the CVS logs for the module in which the bug is in, you can tell who has most recently been involved in that code and send them an email about the bug.
Heh. Never worked for me. Ah well, now I can fix things myself instead. :-) A bug day might be a good idea to do before a bug fix release... I could do one next week, or is that too late?
I am assigned to fix this. I will make time to do it over the holiday. Time has been extremely short for me (and basically all of us at ZC) lately, so your patience is appreciated. I'm assuming we will not have bug day before 2.6.1, but perhaps one shortly thereafter is in order? -Casey On Wednesday 27 November 2002 12:31 pm, Wolfgang Strobl wrote:
On 27 Nov 2002, 11:18 seb bacon wrote:
Can we have a bugfix release?
Me too. I'd like to get the fix for Issue 597 (http://collector.zope.org/Zope/597) in such a bugfix release. ZCTextIndex, quite different from the old TextIndex, currently is almost unusuable outside the US, because it isn't locale aware.
A fix was posted to the collector during the 2.6 beta period, about two weeks BEFORE (!) the release of 2.6.0, by Maik Jablonski, but has been ignored, since.. It's still not checked in, if I'm not mistaken. :-(
What is beta testing good, if the error reports get ignored? Why write patches, if those patches are thrown away?
I'll drop in another (and final) plug for the one-line change needed to undo the harmful http://collector.zope.org/Zope/432 . Andreas, it looked like you were going to fix this for 2.6.0 . Did it slip through the cracks or are you having second thoughts ? Recap: Andreas made ' take precedence over everything including sgml tags, breaking dtml python expressions in zwiki stx pages. I've since found an easy way to work around this for zwiki, but it adds one more behavioural difference & code duplication between zwiki's and zope's stx. Better to avoid this. Regards - Simon
participants (16)
-
Andreas Jung -
Brian Lloyd -
Casey Duncan -
Chris McDonough -
Chris Withers -
Guido van Rossum -
jeremy＠zope.com -
Lennart Regebro -
Lennart Regebro -
Magnus Heino -
R. David Murray -
seb bacon -
Simon Michael -
Toby Dickenson -
Wolfgang Strobl -
Yuppie