Re: [Zope-Coders] DateTime screwup on 2.6 branch and HEAD
I think this screwup of mine well cause a lot problems starting next week. Maybe it's a good idea to make a hotfix for it? I know 2.6.1 is supposed to be finished pretty soon but not within a week, right? :-) +1/-1. I'll make one if you agree it's a good idea, it's a trivial fix. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
Lennart Regebro wrote:
I think this screwup of mine well cause a lot problems starting next week. Maybe it's a good idea to make a hotfix for it? I know 2.6.1 is supposed to be finished pretty soon but not within a week, right? :-)
+1/-1. I'll make one if you agree it's a good idea, it's a trivial fix.
Can you briefly spell out what the consequences are, and exactly what situations + versions of Zope the problems apply to? -- Steve Alexander
From: "Steve Alexander" <steve@cat-box.net>
Can you briefly spell out what the consequences are, and exactly what situations + versions of Zope the problems apply to?
DateTime.rfc822() will not work if you don't have daylight saving, and DateTime.rfc822() is called when you send mails with MailHost. This applies to 2.6.0 only.
I don't think this warrants a hotfix, they are really only for dire security bugs affecting multiple Zope versions. for example, even a bug security hole affecting Zope 2.6.0 (but no other Zope versions) wouldn't warrant a hotfix. I would post a patch here and to the collector. If it seriously affects many users then they can raise their voice so that 2.6.1 gets done quicker. Please upgrade the test suite to test for this bug if possible. -Casey On Mon, 21 Oct 2002 13:50:42 +0200 "Lennart Regebro" <lennart@torped.se> wrote:
From: "Steve Alexander" <steve@cat-box.net>
Can you briefly spell out what the consequences are, and exactly what situations + versions of Zope the problems apply to?
DateTime.rfc822() will not work if you don't have daylight saving, and DateTime.rfc822() is called when you send mails with MailHost. This applies to 2.6.0 only.
On Monday 21 Oct 2002 2:35 pm, Casey Duncan wrote:
I don't think this warrants a hotfix, they are really only for dire security bugs affecting multiple Zope versions. for example, even a bug security hole affecting Zope 2.6.0 (but no other Zope versions) wouldn't warrant a hotfix.
I would post a patch here and to the collector.
If it seriously affects many users then they can raise their voice so that 2.6.1 gets done quicker.
From the description below, it sounds like we need this asap.
DateTime.rfc822() will not work if you don't have daylight saving, and DateTime.rfc822() is called when you send mails with MailHost. This applies to 2.6.0 only.
We need to think about a serious overhaul of the release procedure before next time round....
From: "Toby Dickenson" <tdickenson@geminidataloggers.com>
We need to think about a serious overhaul of the release procedure before next time round....
One big problem here is that the beta2 was released "in the middle of a fix" so to speak. I had fixed the MailHost date bug making MailHost use DateTime.rfc822(). Then beta2 was released, and somebody pointed out that there was a bug in rfc822(). That bug was fixed just before the final came out, and since I had fixed "half" of #411, I thought I should fix all of it. Had I known beta 2 was to be released just the day after I fixed MailHost, I would probably have let the 2_6-branch be, since the bugs weren't serious, just to make sure serious bugs wouldn't be introduced by mistake. I surely would not have added it if I had released that 2.6.0 was just days away. So next time I would like a warning before beta2 is released, and I also think that the test period for beta2 should be a bit longer than three days. I don't think many bugs will be found in that short period. Just my 2 cents. Best Regards Lennart Regebro, Torped http://www.easypublisher.com/
On Mon, 21 Oct 2002 16:20:19 +0200 "Lennart Regebro" <lennart@torped.se> wrote:
From: "Toby Dickenson" <tdickenson@geminidataloggers.com>
We need to think about a serious overhaul of the release procedure before next time round....
One big problem here is that the beta2 was released "in the middle of a fix" so to speak. I had fixed the MailHost date bug making MailHost use DateTime.rfc822(). Then beta2 was released, and somebody pointed out that there was a bug in rfc822(). That bug was fixed just before the final came out, and since I had fixed "half" of #411, I thought I should fix all of it.
Had I known beta 2 was to be released just the day after I fixed MailHost, I would probably have let the 2_6-branch be, since the bugs weren't serious, just to make sure serious bugs wouldn't be introduced by mistake. I surely would not have added it if I had released that 2.6.0 was just days away.
So next time I would like a warning before beta2 is released, and I also think that the test period for beta2 should be a bit longer than three days. I don't think many bugs will be found in that short period.
Just my 2 cents.
This is in no way a defense of the release tactics for 2.6.0, but these types of changes should be done on their own branch and then merged in atomically to avoid exactly this type of issue. In theory (playing by the book) all changes should be made on branches then merged to the HEAD. -Casey
From: "Casey Duncan" <casey@zope.com>
This is in no way a defense of the release tactics for 2.6.0, but these types of changes should be done on their own branch and then merged in atomically to avoid exactly this type of issue.
They were. There were two independant, but related, bugs. Both made in their own branch, and merged in atomically.
Lennart Regebro wrote:
From: "Casey Duncan" <casey@zope.com>
This is in no way a defense of the release tactics for 2.6.0, but these types of changes should be done on their own branch and then merged in atomically to avoid exactly this type of issue.
They were. There were two independant, but related, bugs. Both made in their own branch, and merged in atomically.
Personally, I'd put this down to bad luck. Bugs are bugs and you don't know they're there until you notice them. I don't think there was anything that could have reasonably been done to prevent this. That said, can we see if we can actually get 2.6.1 out within a week (OK, lets be sane and say month ;-). This is open source, lets release early and often... cheers, Chris
On Monday 21 Oct 2002 3:52 pm, Casey Duncan wrote:
This is in no way a defense of the release tactics for 2.6.0, but these types of changes should be done on their own branch and then merged in atomically to avoid exactly this type of issue.
For what its worth, IMO, DateTime was not so broken as to deserve any changes once the first beta release was out the door. It should have waited for 2.7.0.
On Mon, 21 Oct 2002 15:11:09 +0100 Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
On Monday 21 Oct 2002 2:35 pm, Casey Duncan wrote:
I don't think this warrants a hotfix, they are really only for dire security bugs affecting multiple Zope versions. for example, even a bug security hole affecting Zope 2.6.0 (but no other Zope versions) wouldn't warrant a hotfix.
I would post a patch here and to the collector.
If it seriously affects many users then they can raise their voice so that 2.6.1 gets done quicker.
From the description below, it sounds like we need this asap.
DateTime.rfc822() will not work if you don't have daylight saving, and DateTime.rfc822() is called when you send mails with MailHost. This applies to 2.6.0 only.
We need to think about a serious overhaul of the release procedure before next time round....
You imply that there was one ;^) No argument here. -Casey
From: "Casey Duncan" <casey@zope.com>
I would post a patch here and to the collector.
The bug is fixed in the CVS already.
If it seriously affects many users then they can raise their voice so that 2.6.1 gets done quicker.
Well, it will affect all 2.6.0 users using MailHost starting monday morning. Maybe that isn't that many.
Please upgrade the test suite to test for this bug if possible.
I've been thinking about ways to do that. If I figure one out, I will.
participants (5)
-
Casey Duncan -
Chris Withers -
Lennart Regebro -
Steve Alexander -
Toby Dickenson