Mailing List Archive

On Sat, 2004-09-04 at 10:54, Andreas Jung wrote:
> Hi,
>
> I am back from vacation. Can someone update me about the necessity of 2.7.3
> release
> and the status of code on the SVN trunk (for a planned 2.8 released this
> month)?

The last time I looked, the SVN trunk was in a bit of a sorry state.
Before attempting a 2.8 release, it would be helpful if a variety of
people could try to:

- 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.

- C


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

On Sep 4, 2004, at 16:54, Andreas Jung wrote:

> Hi,
>
> I am back from vacation. Can someone update me about the necessity of
> 2.7.3 release
> and the status of code on the SVN trunk (for a planned 2.8 released
> this month)?

IMHO 2.7.3 is needed. There were some very important ZODB fixes from
Tim, among other things.

jens

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

--On Samstag, 4. September 2004 19:03 Uhr +0200 Jens Vagelpohl
<jens@dataflake.org> wrote:

>
> On Sep 4, 2004, at 16:54, Andreas Jung wrote:
>
>> Hi,
>>
>> I am back from vacation. Can someone update me about the necessity of
>> 2.7.3 release
>> and the status of code on the SVN trunk (for a planned 2.8 released
>> this month)?
>
> IMHO 2.7.3 is needed. There were some very important ZODB fixes from Tim,
> among other things.

Ok, I will care about the 2.7.3RC1 release during the week.

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

2.7.3 should be delayed while we fix the publisher to cope with recent
ZODB changes as documented at http://collectors.zope.org/Zope/789 .



On Sat, 2004-09-04 at 13:03, Jens Vagelpohl wrote:
> On Sep 4, 2004, at 16:54, Andreas Jung wrote:
>
> > Hi,
> >
> > I am back from vacation. Can someone update me about the necessity of
> > 2.7.3 release
> > and the status of code on the SVN trunk (for a planned 2.8 released
> > this month)?
>
> IMHO 2.7.3 is needed. There were some very important ZODB fixes from
> Tim, among other things.
>
> jens
>
> _______________________________________________
> 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

Ok, thanks for the update.

Andreas

--On Samstag, 4. September 2004 13:22 Uhr -0400 Chris McDonough
<chrism@plope.com> wrote:

> 2.7.3 should be delayed while we fix the publisher to cope with recent
> ZODB changes as documented at http://collectors.zope.org/Zope/789 .
>
>
>
> On Sat, 2004-09-04 at 13:03, Jens Vagelpohl wrote:
>> On Sep 4, 2004, at 16:54, Andreas Jung wrote:
>>
>> > Hi,
>> >
>> > I am back from vacation. Can someone update me about the necessity of
>> > 2.7.3 release
>> > and the status of code on the SVN trunk (for a planned 2.8 released
>> > this month)?
>>
>> IMHO 2.7.3 is needed. There were some very important ZODB fixes from
>> Tim, among other things.
>>
>> jens
>>
>> _______________________________________________
>> 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




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

Andreas Jung wrote:
> Ok, thanks for the update.
>
> Andreas
>
> --On Samstag, 4. September 2004 13:22 Uhr -0400 Chris McDonough
> <chrism@plope.com> wrote:
>
>> 2.7.3 should be delayed while we fix the publisher to cope with recent
>> ZODB changes as documented at http://collectors.zope.org/Zope/789 .

We do need to find a way to get the ZPublisher stuff done soon, as the
other pending changes for 2.7 (the security issue for the last hotfix,
for one) are pretty important.

I find it ironic, at least, that the subtransaction-leaves-turds bug has
bitten me almost every day since it was identified (and never before
that, if memory serves).

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

Andreas Jung wrote:
> Ok, thanks for the update.
>
> Andreas
>
> --On Samstag, 4. September 2004 13:22 Uhr -0400 Chris McDonough
> <chrism@plope.com> wrote:
>
>> 2.7.3 should be delayed while we fix the publisher to cope with recent
>> ZODB changes as documented at http://collectors.zope.org/Zope/789 .

We do need to find a way to get the ZPublisher stuff done soon, as the
other pending changes for 2.7 (the security issue for the last hotfix,
for one) are pretty important.

I find it ironic, at least, that the subtransaction-leaves-turds bug has
bitten me almost every day since it was identified (and never before
that, if memory serves).

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

Am Sa, den 04.09.2004 schrieb Tres Seaver um 21:44:
> Andreas Jung wrote:
> > Ok, thanks for the update.
> >
> > Andreas
> >
> > --On Samstag, 4. September 2004 13:22 Uhr -0400 Chris McDonough
> > <chrism@plope.com> wrote:
> >
> >> 2.7.3 should be delayed while we fix the publisher to cope with recent
> >> ZODB changes as documented at http://collectors.zope.org/Zope/789 .
>
> We do need to find a way to get the ZPublisher stuff done soon, as the
> other pending changes for 2.7 (the security issue for the last hotfix,
> for one) are pretty important.
>
> I find it ironic, at least, that the subtransaction-leaves-turds bug has
> bitten me almost every day since it was identified (and never before
> that, if memory serves).

Almost sure a case of:
http://catb.org/~esr/jargon/html/S/schroedinbug.html

;-)
Tino

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

[Andreas Jung]
> I am back from vacation.

Welcome back!

> Can someone update me about the necessity of 2.7.3 release

"Critical" is quite arguable, but has been covered by others.

> and the status of code on the SVN trunk (for a planned 2.8 released
> this month)?

That one's much harder to judge. I haven't seen evidence of work done
on the SVN Zope trunk since it was created.

Note that It's very different than the 2.7 CVS setup: in CVS, the
modules for (at least) ZODB/ZEO, ZConfig, and zdaemon are shared
across checkouts. So, e.g., when I check something in to a ZODB3
module checkout, it shows up in a Zope module checkout automatically.
Or if I check it in from a Zope checkout, it shows up in a ZODB3
checkout. Likewise for (at least) ZConfig and zdaemon.

But in the SVN setup, none of that is true: Zope has its own,
distinct, *copies* of (at least) ZODB/ZEO, ZConfig and zdaemon, and
checking something in from a checkout of one of those has no effect on
checkouts of any of the others.

So, for example, I'm sure that the SVN Zope trunk still has the copies
of (at least) ZODB/ZEO, ZConfig, and zdaemon as of the day Jim first
set up the SVN Zope trunk, so still suffers from all bugs in those
things that have been fixed since then.

I liked the CVS arrangement better. As is, it's nobody's official
responsiblity to keep the SVN Zope trunk in synch with the "external"
core code Zope relies on, and a predictable consequence is
"unexpected" integration problems when someone decides to slam in new
copies of these things right before a release. Indeed, we just went
thru a round of that when slamming a current ZODB/ZEO into the Zope X3
branch for the latter's beta 4 release (it turned out that some of the
X3 tests were relying on accidents of transaction semantics).

In short, life is more brutal on the SVN trunk, and for several reasons.
_______________________________________________
Zope-Coders mailing list
Zope-Coders@zope.org
http://mail.zope.org/mailman/listinfo/zope-coders

On 5/09/2004, at 5:03 AM, Jens Vagelpohl wrote:

>
> On Sep 4, 2004, at 16:54, Andreas Jung wrote:
>
>> Hi,
>>
>> I am back from vacation. Can someone update me about the necessity of
>> 2.7.3 release
>> and the status of code on the SVN trunk (for a planned 2.8 released
>> this month)?
>
> IMHO 2.7.3 is needed. There were some very important ZODB fixes from
> Tim, among other things.

I think it would be useful to get the attached patch into 2.7.3.

It is a fix to ensure that all transaction are always either commited
or aborted. Previously if an error bubbled up to Zope's publishing
machinery during execution of the publishing error handler then the
transaction was not aborted. (It would have been aborted from the begin
of the following transaction but that has been recently advertised as
non-ideal.)

It is the same patch that I have posted before to zope-dev. This one
though includes a test for that. Chris has replied off line and is
comfortable with this.

I've been using this in testing sessions using latest of 2_7-branch -
includes ZODB fixes from Tim. So far it seems that this patch is a
pretty important step to ironing out a lot of the problems with
sessions.

Any objections?

michael

Beautiful, thank you! I have committed this.

The failing test (caused by a run against a Zope *without* your
Publish.py patches) is a nice dose of clarity.

======================================================================
ERROR: doctest of ZPublisher.tests.testPublish.testPublisher
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/chrism/opt/Python-2.3.4/lib/python2.3/unittest.py", line
423, in runTest
self.__testFunc()
File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
1359, in runit
_utest(tester, name, doc, filename, lineno)
File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
1309, in _utest
raise DocTestTestFailure('Failed doctest test for %s\n'
DocTestTestFailure: Failed doctest test for
ZPublisher.tests.testPublish.testPublisher
File
"/home/chrism/software/27Branch/lib/python/ZPublisher/tests/testPublish.py", line 126, in testPublisher

*****************************************************************
Failure in example: tracer.showTracedPath()
from line #47 of ZPublisher.tests.testPublish.testPublisher
Expected:
begin
__call__
raising ValueError from __call__
zpublisher_exception_hook
raising ValueError from zpublisher_exception_hook
abort
Got:
begin
__call__
raising ValueError from __call__
zpublisher_exception_hook
raising ValueError from zpublisher_exception_hook
*****************************************************************
Failure in example: tracer.showTracedPath()
from line #103 of ZPublisher.tests.testPublish.testPublisher
Expected:
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
abort
Got:
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
abort
begin
__call__
raising ConflictError from __call__
*****************************************************************
Failure in example: tracer.showTracedPath()
from line #132 of ZPublisher.tests.testPublish.testPublisher
Expected:
begin
__call__
raising ValueError from __call__
zpublisher_exception_hook
raising ConflictError from zpublisher_exception_hook
abort
Got:
begin
__call__
raising ValueError from __call__
zpublisher_exception_hook
raising ConflictError from zpublisher_exception_hook


On Sat, 2004-09-04 at 16:46, Michael Dunstan wrote:
> On 5/09/2004, at 5:03 AM, Jens Vagelpohl wrote:
>
> >
> > On Sep 4, 2004, at 16:54, Andreas Jung wrote:
> >
> >> Hi,
> >>
> >> I am back from vacation. Can someone update me about the necessity of
> >> 2.7.3 release
> >> and the status of code on the SVN trunk (for a planned 2.8 released
> >> this month)?
> >
> > IMHO 2.7.3 is needed. There were some very important ZODB fixes from
> > Tim, among other things.
>
> I think it would be useful to get the attached patch into 2.7.3.
>
> It is a fix to ensure that all transaction are always either commited
> or aborted. Previously if an error bubbled up to Zope's publishing
> machinery during execution of the publishing error handler then the
> transaction was not aborted. (It would have been aborted from the begin
> of the following transaction but that has been recently advertised as
> non-ideal.)
>
> It is the same patch that I have posted before to zope-dev. This one
> though includes a test for that. Chris has replied off line and is
> comfortable with this.
>
> I've been using this in testing sessions using latest of 2_7-branch -
> includes ZODB fixes from Tim. So far it seems that this patch is a
> pretty important step to ironing out a lot of the problems with
> sessions.
>
> Any objections?
>
> michael
>
>
> ______________________________________________________________________
> _______________________________________________
> 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

Is this issue now resolved with your fixes? At least from my point of view
the unittests are
running for the latest 2.7 checkout.

Andreas

--On Samstag, 4. September 2004 22:44 Uhr -0400 Chris McDonough
<chrism@plope.com> wrote:

> Beautiful, thank you! I have committed this.
>
> The failing test (caused by a run against a Zope *without* your
> Publish.py patches) is a nice dose of clarity.
>
> ======================================================================
> ERROR: doctest of ZPublisher.tests.testPublish.testPublisher
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/chrism/opt/Python-2.3.4/lib/python2.3/unittest.py", line
> 423, in runTest
> self.__testFunc()
> File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
> 1359, in runit
> _utest(tester, name, doc, filename, lineno)
> File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
> 1309, in _utest
> raise DocTestTestFailure('Failed doctest test for %s\n'
> DocTestTestFailure: Failed doctest test for
> ZPublisher.tests.testPublish.testPublisher
> File
> "/home/chrism/software/27Branch/lib/python/ZPublisher/tests/testPublish.p
> y", line 126, in testPublisher
> *****************************************************************
> Failure in example: tracer.showTracedPath()
> from line #47 of ZPublisher.tests.testPublish.testPublisher
> Expected:
> begin
> __call__
> raising ValueError from __call__
> zpublisher_exception_hook
> raising ValueError from zpublisher_exception_hook
> abort
> Got:
> begin
> __call__
> raising ValueError from __call__
> zpublisher_exception_hook
> raising ValueError from zpublisher_exception_hook
> *****************************************************************
> Failure in example: tracer.showTracedPath()
> from line #103 of ZPublisher.tests.testPublish.testPublisher
> Expected:
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> abort
> Got:
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> abort
> begin
> __call__
> raising ConflictError from __call__
> *****************************************************************
> Failure in example: tracer.showTracedPath()
> from line #132 of ZPublisher.tests.testPublish.testPublisher
> Expected:
> begin
> __call__
> raising ValueError from __call__
> zpublisher_exception_hook
> raising ConflictError from zpublisher_exception_hook
> abort
> Got:
> begin
> __call__
> raising ValueError from __call__
> zpublisher_exception_hook
> raising ConflictError from zpublisher_exception_hook
>
>
> On Sat, 2004-09-04 at 16:46, Michael Dunstan wrote:
>> On 5/09/2004, at 5:03 AM, Jens Vagelpohl wrote:
>>
>> >
>> > On Sep 4, 2004, at 16:54, Andreas Jung wrote:
>> >
>> >> Hi,
>> >>
>> >> I am back from vacation. Can someone update me about the necessity of
>> >> 2.7.3 release
>> >> and the status of code on the SVN trunk (for a planned 2.8 released
>> >> this month)?
>> >
>> > IMHO 2.7.3 is needed. There were some very important ZODB fixes from
>> > Tim, among other things.
>>
>> I think it would be useful to get the attached patch into 2.7.3.
>>
>> It is a fix to ensure that all transaction are always either commited
>> or aborted. Previously if an error bubbled up to Zope's publishing
>> machinery during execution of the publishing error handler then the
>> transaction was not aborted. (It would have been aborted from the begin
>> of the following transaction but that has been recently advertised as
>> non-ideal.)
>>
>> It is the same patch that I have posted before to zope-dev. This one
>> though includes a test for that. Chris has replied off line and is
>> comfortable with this.
>>
>> I've been using this in testing sessions using latest of 2_7-branch -
>> includes ZODB fixes from Tim. So far it seems that this patch is a
>> pretty important step to ironing out a lot of the problems with
>> sessions.
>>
>> Any objections?
>>
>> michael
>>
>>
>> ______________________________________________________________________
>> _______________________________________________
>> 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




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

Yep. Applying dunny's patch fixes the publisher issue.

FWIW, this patch apparently fixes a large percentage of
sessioning-related issues (as well as probably other intermittent bata
integrity issues). But as nice as that is, there are some other bugs in
Transience that need to be fixed and tested as well (also detected by
dunny).

Do you have a preconceived idea of a schedule for 2.7.3? I forget, do
you release alphas or go right to beta? Will it be ok to add some
Transience changes in later this week/next week? I'd really like 2.7.3
to be the "sessions are fixed; no, really this time" release but it
might take me until maybe the 17th to do the appropriate testing.

- C


On Mon, 2004-09-06 at 14:53, Andreas Jung wrote:
> Is this issue now resolved with your fixes? At least from my point of view
> the unittests are
> running for the latest 2.7 checkout.
>
> Andreas
>
> --On Samstag, 4. September 2004 22:44 Uhr -0400 Chris McDonough
> <chrism@plope.com> wrote:
>
> > Beautiful, thank you! I have committed this.
> >
> > The failing test (caused by a run against a Zope *without* your
> > Publish.py patches) is a nice dose of clarity.
> >
> > ======================================================================
> > ERROR: doctest of ZPublisher.tests.testPublish.testPublisher
> > ----------------------------------------------------------------------
> > Traceback (most recent call last):
> > File "/home/chrism/opt/Python-2.3.4/lib/python2.3/unittest.py", line
> > 423, in runTest
> > self.__testFunc()
> > File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
> > 1359, in runit
> > _utest(tester, name, doc, filename, lineno)
> > File "/home/chrism/opt/Python-2.3.4/lib/python2.3/doctest.py", line
> > 1309, in _utest
> > raise DocTestTestFailure('Failed doctest test for %s\n'
> > DocTestTestFailure: Failed doctest test for
> > ZPublisher.tests.testPublish.testPublisher
> > File
> > "/home/chrism/software/27Branch/lib/python/ZPublisher/tests/testPublish.p
> > y", line 126, in testPublisher
> > *****************************************************************
> > Failure in example: tracer.showTracedPath()
> > from line #47 of ZPublisher.tests.testPublish.testPublisher
> > Expected:
> > begin
> > __call__
> > raising ValueError from __call__
> > zpublisher_exception_hook
> > raising ValueError from zpublisher_exception_hook
> > abort
> > Got:
> > begin
> > __call__
> > raising ValueError from __call__
> > zpublisher_exception_hook
> > raising ValueError from zpublisher_exception_hook
> > *****************************************************************
> > Failure in example: tracer.showTracedPath()
> > from line #103 of ZPublisher.tests.testPublish.testPublisher
> > Expected:
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > Got:
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > abort
> > begin
> > __call__
> > raising ConflictError from __call__
> > *****************************************************************
> > Failure in example: tracer.showTracedPath()
> > from line #132 of ZPublisher.tests.testPublish.testPublisher
> > Expected:
> > begin
> > __call__
> > raising ValueError from __call__
> > zpublisher_exception_hook
> > raising ConflictError from zpublisher_exception_hook
> > abort
> > Got:
> > begin
> > __call__
> > raising ValueError from __call__
> > zpublisher_exception_hook
> > raising ConflictError from zpublisher_exception_hook
> >
> >
> > On Sat, 2004-09-04 at 16:46, Michael Dunstan wrote:
> >> On 5/09/2004, at 5:03 AM, Jens Vagelpohl wrote:
> >>
> >> >
> >> > On Sep 4, 2004, at 16:54, Andreas Jung wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I am back from vacation. Can someone update me about the necessity of
> >> >> 2.7.3 release
> >> >> and the status of code on the SVN trunk (for a planned 2.8 released
> >> >> this month)?
> >> >
> >> > IMHO 2.7.3 is needed. There were some very important ZODB fixes from
> >> > Tim, among other things.
> >>
> >> I think it would be useful to get the attached patch into 2.7.3.
> >>
> >> It is a fix to ensure that all transaction are always either commited
> >> or aborted. Previously if an error bubbled up to Zope's publishing
> >> machinery during execution of the publishing error handler then the
> >> transaction was not aborted. (It would have been aborted from the begin
> >> of the following transaction but that has been recently advertised as
> >> non-ideal.)
> >>
> >> It is the same patch that I have posted before to zope-dev. This one
> >> though includes a test for that. Chris has replied off line and is
> >> comfortable with this.
> >>
> >> I've been using this in testing sessions using latest of 2_7-branch -
> >> includes ZODB fixes from Tim. So far it seems that this patch is a
> >> pretty important step to ironing out a lot of the problems with
> >> sessions.
> >>
> >> Any objections?
> >>
> >> michael
> >>
> >>
> >> ______________________________________________________________________
> >> _______________________________________________
> >> 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
>
>
>
> Andreas Jung
> zopyx.com - Software Development and Consulting Andreas Jung
>

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

--On Montag, 6. September 2004 15:04 Uhr -0400 Chris McDonough
<chrism@plope.com> wrote:

> Yep. Applying dunny's patch fixes the publisher issue.
>
> FWIW, this patch apparently fixes a large percentage of
> sessioning-related issues (as well as probably other intermittent bata
> integrity issues). But as nice as that is, there are some other bugs in
> Transience that need to be fixed and tested as well (also detected by
> dunny).

sounds great

>
> Do you have a preconceived idea of a schedule for 2.7.3? I forget, do
> you release alphas or go right to beta? Will it be ok to add some
> Transience changes in later this week/next week? I'd really like 2.7.3
> to be the "sessions are fixed; no, really this time" release but it
> might take me until maybe the 17th to do the appropriate testing.

A stable session machinery has a higher prio than making this release
this week. If you have things that must be fixed then they should be fixed
before a first beta, alpha or whatever (maybe one beta + one RC should do
the job)
for 2.7.3. So 2.7.3-something release after the shortly after Plone Conf.
would work.

Andreas


Andreas Jung
zopyx.com - Software Development and Consulting Andreas Jung

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