Mailing List Archive

On Sat, 2004-09-18 at 02:52, Andreas Jung wrote:
> Hi everyone,
>
> I am going to release Zope 2.7.3 beta 1 on October, 27th. Please finish
> pending jobs before the release.

FWIW, the sessioning stuff is completed for 2.7.3. There may be minor
configuration changes, but no more major code changes.

> Zope 2.8 alpha 1 will be released during the same week. This release will
> properly ship with a broken ZClasses
> implementation. Releasing 2.8 now is more important than waiting until
> someone (Jim) has fixed the ZClasses.
> This does not mean that ZClasses will be gone in 2.8. They will be still
> supported as in the latest releases.

Has anyone been able to confirm or investigate the list of "2.8 issues"
I last sent over to this list (or maybe it was zope-dev)? FWIW, I
suspect it would be a mistake to make any release without at least
reviewing and acknowledging these. They are repeated below.

- reproduce this hanging symptom (instructions provided):
http://zope.org/Collectors/Zope/1350

- test that Zope 2.8 starts up and works properly with databases
created under Zope 2.7 and earlier. Lots of problems in this
area the last time I checked.

- Confirm that mounted databases still don't work:
http://zope.org/Collectors/Zope/1305

- Confirm that this Catalog-related issue needs to be fixed:
http://zope.org/Collectors/Zope/1332

- Test with Plone (I found a number of places where Plone
needed to declare its own docstrings on methods of
classes overridden from CMF). See
http://www.plope.com/Members/chrism/plone_on_zope_head/view
for more info.

Also, FWIW, Tim is on vacation and ZODB in 2.8 is in an unknown state
(it's not linked in any automated way to the ZODB 3.3 that Zope 3 is
using, so someone needs to do that merge). It is probably a year old or
so, maybe.

- C


_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Samstag, 18. September 2004 10:49 Uhr -0400 Chris McDonough
<chrism@plope.com> wrote:

> Has anyone been able to confirm or investigate the list of "2.8 issues"
> I last sent over to this list (or maybe it was zope-dev)? FWIW, I
> suspect it would be a mistake to make any release without at least
> reviewing and acknowledging these. They are repeated below.

Good point.

>
> - test that Zope 2.8 starts up and works properly with databases
> created under Zope 2.7 and earlier. Lots of problems in this
> area the last time I checked.

Works for me with some large Plone sites. However there are
problems importing PersistentList and PersistentMapping
from the ZODB package.
>
> Also, FWIW, Tim is on vacation and ZODB in 2.8 is in an unknown state
> (it's not linked in any automated way to the ZODB 3.3 that Zope 3 is
> using, so someone needs to do that merge). It is probably a year old or
> so, maybe.
>

Ok. Since there is no need to hurry with 2.8 we can decide to make
the a1 release when most annoying issues are resolved.

Andreas


_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[Andreas Jung]
> I am going to release Zope 2.7.3 beta 1 on October, 27th. Please finish
> pending jobs before the release.

Did you mean Wednesday, October 27? Or did you mean Monday, September 27?

> Zope 2.8 alpha 1 will be released during the same week.

If you meant September, I doubt it <wink>.

> This release will properly ship with a broken ZClasses implementation.
> Releasing 2.8 now

The "now" here makes me suspect you meant September.

> is more important than waiting until someone (Jim) has fixed the ZClasses.
> This does not mean that ZClasses will be gone in 2.8. They will be still
> supported as in the latest releases.

Sorry, this didn't make sense to me. The "still supported" in the
last sentence doesn't seem to jibe with the "broken" two sentences
back.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[Chris McDonough]
...
> Also, FWIW, Tim is on vacation

This is true, although it's hard to tell that with me typing here <wink>.

> and ZODB in 2.8 is in an unknown state (it's not linked in any automated
> way to the ZODB 3.3 that Zope 3 is using,

None of ZODB, ZConfig, or zdaemon are linked in any automated way to
any version of Zope under SVN. Zope trunk ("2.8"), Zope3 trunk, and
Zope X3 branch each have their own distinct copies of ZODB, ZConfig,
and zdaemon. Checking in from one copy has no effect on any other
copy. For that matter, the ZODB trunk and branch each have their own
distinct copies of ZConfig and zdaemon too. The CVS setup was
night-and-day different here, where a checkin from any checkout was
instantly seen by all clients. There are good and bad points for both
ways of doing it.

The unique thing about Zope trunk right now is that it doesn't *look*
like the job of stitching (*a* copy of) SVN ZODB into it was left in a
wholly sane state.

> so someone needs to do that merge).

Yes. Perhaps for ZConfig and zdaemon too.

> It is probably a year old or so, maybe.

I don't think it's *that* bad. It looks like Zope trunk has ZODB3 as
of the day Jim first converted CVS to SVN, plus a random checkin made
to ZODB/component.xml that should not have been made from a Zope
checkout, plus some aborted old attempt to try to update ZODB to an
early 3.3 alpha state.

I *expect* this will be easy to repair, if I can get bandwidth from
Jim to clarify how he originally stitched ZODB into Zope trunk (it's a
multi-step process, essentially copying one ZODB directory at a time
into a different place in the Zope trunk; one of the things I don't
know is exactly which set of ZODB directories he copied, and it
doesn't appear to be the same set as got copied into Zope3/ZopeX3).
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[.Tim Peters, a week ago Saturday, about Zope trunk under SVN]
> None of ZODB, ZConfig, or zdaemon are linked in any automated way to
> any version of Zope under SVN. Zope trunk ("2.8"), Zope3 trunk, and
> Zope X3 branch each have their own distinct copies of ZODB, ZConfig,
> and zdaemon. Checking in from one copy has no effect on any other
> copy. For that matter, the ZODB trunk and branch each have their own
> distinct copies of ZConfig and zdaemon too.

... [.and the ZODB copy in Zope trunk was at best 4 months old] ...

> I *expect* this will be easy to repair, if I can get bandwidth from
> Jim to clarify how he originally stitched ZODB into Zope trunk ...

I'm back from vacation, and think I'm nearing the end of this part.
If final tests pass, I'll check it in, probably within an hour. "It"
means stitching a current version of ZODB 3.3 into Zope trunk, plus
enough other changes so that the Zope tests all pass again.

That specifically means these 8 directories under Zope's lib/python/,
copied from the same-named directories under ZODB's src/ directory:

ZODB
ZEO
persistent
transaction
BTrees
ThreadedAsync
Persistence
ZopeUndo

and also Zope's utilities/ZODBTools/ directory, which is a renamed
copy of ZODB's src/scripts/ directory.

I have not looked at the state of ZConfig or zdaemon in Zope trunk,
and probably won't (I don't know much about them).

I also need to check in a number of changes to Zope trunk's tests, to
account for that:

1. Transaction.begin() is deprecated, and dangerous, in 3.3. The correct
spelling is now:

import transaction
transaction.begin()

It's "dangerous" for reasons explained in ZODB's NEWS file; in short, while

txn.begin()

still aborts the current transaction and starts a new one, it creates a new
transaction *object* too -- 'txn' is no longer the current transaction object
after 'txn.begin()'. That's deadly in the (very) few cases where people go
on to use 'txn'. Much more common is the spelling:

get_transaction().begin()

and that's harmless (although it's still deprecated, and will go away ASAP
after 3.3).

2. Failure of a transaction to commit is "sticky" in 3.3 now -- all subsequent
attempts to commit will continue to fail, until the transaction is explicitly
aborted, or transaction.begin() is called. Curiously, the problem I've had
with that so far is in the newer Transience tests. UncommittableJar had
to grow a new do-nothing abort() method (so that the transaction it's
involved with *can* be explicitly aborted), and TestTransactionHelper.
testUncommittable() had to add "transaction.abort()" at the end, else
the commit failure that test provoked prevented future tests from doing
a commit too.

So I think ZODB 3.3 in Zope trunk will be in good shape again starting
tonight. I don't know about ZConfig, zdaemon, or the spurt of
non-ZODB bugfixes that went into (what will soon be) Zope 2.7.3.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[Tim Peters]
> I'm back from vacation, and think I'm nearing the end of this part.
> If final tests pass, I'll check it in, probably within an hour. "It"
> means stitching a current version of ZODB 3.3 into Zope trunk, plus
> enough other changes so that the Zope tests all pass again.

...

Heh. I did check it in, but Zope-Checkins decided I wasn't allowed to
post to that list so apparently swallowed the checkin comments and
diffs. That's pretty bizarre, since *I* didn't mail anything to
Zope-Checkins; I'm not sure "who" it thinks sends the atuo-generated
checkin email.

Whatever, ZODB 3.3 is stitched into Zope trunk now, and all the tests pass.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Mon, 27 Sep 2004, Tim Peters wrote:

> [Tim Peters]
> > I'm back from vacation, and think I'm nearing the end of this part.
> > If final tests pass, I'll check it in, probably within an hour. "It"
> > means stitching a current version of ZODB 3.3 into Zope trunk, plus
> > enough other changes so that the Zope tests all pass again.
> ...
> Heh. I did check it in, but Zope-Checkins decided I wasn't allowed to
> post to that list so apparently swallowed the checkin comments and
> diffs. That's pretty bizarre, since *I* didn't mail anything to
> Zope-Checkins; I'm not sure "who" it thinks sends the atuo-generated
> checkin email.

That was my fault. I was experimenting with list settings looking to
arrive at a balance that would hold incidental items while allowing
official ones. Turns out that's complicated on the notices list because
the ostensible "from" address is the user's zope.org member address, which
sometimes (probably, often) is not their list subscription address.

I gave up on that first stab, so messages will once again go through
undeterred, and approved tim's held checkin notices. (I also discarded a
piece of spam that would have gone through without this measure, during
the brief time it was in place.)

So i'm thinking about a more viable filtering approach. There's a pretty
obvious and simple one, that would allow only messages that come from the
checkin-notifications mechanism (there is probably some cue in the
headers, we can add one if not). The drawback is that it would discard
incidental comments, which can be valuable - typically, "whoops, did you
really mean to do that?" responses, useful on a checkins list. Those
comments are typically cc'd to the original posters ("checkin-ers"?
"checkers-iners"?), but having them on the list would be ideal.

Come to think of it, the best solution would be to allow both messages
from the checkins mechanism *and* messages from subscribers. I hope
there's a way to do that - anyone know, offhand?

I'll post something when i put a new measure in place, so people won't be
so surprised if things work, um, differently.

thinking-out-loud-is-useful-but-it-probably-looks-funny'ly,
Ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Montag, 27. September 2004 16:09 Uhr -0400 Tim Peters
<tim.peters@gmail.com> wrote:
> I'm back from vacation, and think I'm nearing the end of this part.
> If final tests pass, I'll check it in, probably within an hour. "It"
> means stitching a current version of ZODB 3.3 into Zope trunk, plus
> enough other changes so that the Zope tests all pass again.
>
>

Thanks a lot!

I have done some rough testing but haven't found any serious problems so
long.
I would like to invite everyone to do some testing over the next days so we
can ensure
to release a more or less stable alpha very soon.

Andreas


_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:

> So i'm thinking about a more viable filtering approach. There's a pretty
> obvious and simple one, that would allow only messages that come from the
> checkin-notifications mechanism (there is probably some cue in the
> headers, we can add one if not). The drawback is that it would discard
> incidental comments, which can be valuable - typically, "whoops, did you
> really mean to do that?" responses, useful on a checkins list. Those
> comments are typically cc'd to the original posters ("checkin-ers"?
> "checkers-iners"?), but having them on the list would be ideal.

I don't actually think having replies go to the checkins list is
valuable. What if we hard-wired the 'Reply-to' header to go to the
appropriate -dev list?

> Come to think of it, the best solution would be to allow both messages
> from the checkins mechanism *and* messages from subscribers. I hope
> there's a way to do that - anyone know, offhand?

Could we restrict the checkins to reject anything not coming from the IP
of cvs.zope.org/svn.zope.org?

> I'll post something when i put a new measure in place, so people won't be
> so surprised if things work, um, differently.

Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

Ken Manheimer wrote:

> So i'm thinking about a more viable filtering approach. There's a pretty
> obvious and simple one, that would allow only messages that come from the
> checkin-notifications mechanism (there is probably some cue in the
> headers, we can add one if not). The drawback is that it would discard
> incidental comments, which can be valuable - typically, "whoops, did you
> really mean to do that?" responses, useful on a checkins list. Those
> comments are typically cc'd to the original posters ("checkin-ers"?
> "checkers-iners"?), but having them on the list would be ideal.

I don't actually think having replies go to the checkins list is
valuable. What if we hard-wired the 'Reply-to' header to go to the
appropriate -dev list?

> Come to think of it, the best solution would be to allow both messages
> from the checkins mechanism *and* messages from subscribers. I hope
> there's a way to do that - anyone know, offhand?

Could we restrict the checkins to reject anything not coming from the IP
of cvs.zope.org/svn.zope.org?

> I'll post something when i put a new measure in place, so people won't be
> so surprised if things work, um, differently.

Tres.
--
===============================================================
Tres Seaver tseaver@zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

[Tim Peters]
>> Heh. I did check it in, but Zope-Checkins decided I wasn't allowed to
>> post to that list ...

[Ken Manheimer]
> That was my fault.

Of course it was. I was just too polite to point that out <wink>.

> I was experimenting with list settings looking to arrive at a balance that
> would hold incidental items while allowing official ones. Turns out that's
> complicated on the notices list because the ostensible "from" address is
> the user's zope.org member address, which sometimes (probably, often)
> is not their list subscription address.

I don't expect it's worth worrying much about. I later subscribed to
zope-checkins under the address it sent the "moderator hold" message
to, and then disabled mail delivery on the new subscription. That's
not unique -- I'm probably subscribed to a dozen Zope mailing lists
now under two (or three) addresses.

> I gave up on that first stab, so messages will once again go through
> undeterred, and approved tim's held checkin notices. (I also discarded a
> piece of spam that would have gone through without this measure, during
> the brief time it was in place.)

And if you can discard 100 pieces of spam per day that way, I might
even notice the slight dip in my spam load <wink>.

> So i'm thinking about a more viable filtering approach. There's a pretty
> obvious and simple one, that would allow only messages that come from the
> checkin-notifications mechanism (there is probably some cue in the
> headers, we can add one if not). The drawback is that it would discard
> incidental comments, which can be valuable - typically, "whoops, did you
> really mean to do that?" responses, useful on a checkins list. Those
> comments are typically cc'd to the original posters ("checkin-ers"?
> "checkers-iners"?), but having them on the list would be ideal.

I think they're more useful on the associated -dev list. I expect to
see (only) automated checkin msgs on a -checkins list, and fiddle my
email priorities accordingly. On the Python project, python-checkins
msgs have

Reply-To: python-dev@python.org

set, after several important threads were "lost" on the mostly-ignored
checkins list. The Zope lists appear similar: zope-dev has 10x as
many subscribers as zope-checkins, and even then it looks like half of
the latter have delivery disabled. IOW, checkins lists appear mostly
ignored on all projects.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On Tue, 28 Sep 2004, Tim Peters wrote:

> [Tim Peters]
> >> Heh. I did check it in, but Zope-Checkins decided I wasn't allowed to
> >> post to that list ...
>
> [Ken Manheimer]
> > That was my fault.
>
> Of course it was. I was just too polite to point that out <wink>.

Ah, i should have realized - substitute "but Zope-Checkins decided" ==>
"but That-Bozo-Ken decided".

> > [...]
>
> I don't expect it's worth worrying much about. I later subscribed to
> zope-checkins under the address it sent the "moderator hold" message
> to, and then disabled mail delivery on the new subscription. That's
> not unique -- I'm probably subscribed to a dozen Zope mailing lists
> now under two (or three) addresses.

Well, don't fret that your effort was wasted - my *real* plan was to get
the glory of an additional uncle timbot subscription to zope-checkins -
and my nefarious scheme has succeeded. Your subscriptions all belong to
us!

> And if you can discard 100 pieces of spam per day that way, I might
> even notice the slight dip in my spam load <wink>.

(FWIW, i intended to get to the point where we'll be discarding rather
than holding, once i'd arrived at some reasonable scheme.)

> > [...]
> > headers, we can add one if not). The drawback is that it would discard
> > incidental comments, which can be valuable - typically, "whoops, did you
> > really mean to do that?" responses, useful on a checkins list. Those
>
> I think they're more useful on the associated -dev list. I expect to
> see (only) automated checkin msgs on a -checkins list, and fiddle my
> email priorities accordingly. On the Python project, python-checkins
> msgs have
>
> Reply-To: python-dev@python.org

Tres thinks so, too. I'm convinced. Next opportunity i'll craft it.

> set, after several important threads were "lost" on the mostly-ignored
> checkins list. The Zope lists appear similar: zope-dev has 10x as
> many subscribers as zope-checkins, and even then it looks like half of
> the latter have delivery disabled. IOW, checkins lists appear mostly
> ignored on all projects.

"Many eyes - shut."

Regardless, it'll be easy enough to close the spam hole for the few loyal
readers...

Tnx.
ken
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

--On Samstag, 18. September 2004 8:52 Uhr +0200 Andreas Jung
<lists@andreas-jung.com> wrote:

> Hi everyone,
>
> I am going to release Zope 2.7.3 beta 1 on October, 27th. Please finish
> pending jobs before the release.
>

2.7.3 b2 or RC1 (depending on the fixes over the next week) will be
released on October, 11th.

Andreas
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

FWIW, I would plan on a b2... there have already been a few changes
since 2.7b1 and I know I need to change a sessioning policy (default of
a 20 second resolution time to 60 seconds) too.

On Fri, 2004-10-01 at 01:27, Andreas Jung wrote:
> --On Samstag, 18. September 2004 8:52 Uhr +0200 Andreas Jung
> <lists@andreas-jung.com> wrote:
>
> > Hi everyone,
> >
> > I am going to release Zope 2.7.3 beta 1 on October, 27th. Please finish
> > pending jobs before the release.
> >
>
> 2.7.3 b2 or RC1 (depending on the fixes over the next week) will be
> released on October, 11th.
>
> Andreas
> _______________________________________________
> Zope-Coders mailing list
> Zope-Coders@zope.org
> http://mail.zope.org/mailman/listinfo/zope-coders
>

_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders