Final touches for a 1.0 "proper"

[Jan-Wijbrand Kolman-3]

Hi,

The 1.0b2 has been out for a week or so. At the time of the release we
thought we could do the final very soon after the beta. I'd still like
to do that :-)

A few questions:

* So far there haven't been any showstoppers for a 1.0, right? If there
are, we should see if we can fix them.

* It is not really a show stopper, it would be nice if someone (Martijn,
Uli?) could have a look at what I skethced out here:

http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev

See also the earlier "using zope.testbrowser to test for Unauthorized
exceptions and updated zope.publisher with IReRaise exception support"
thread.

* Besides the regular release procedure, do we need to take extra steps?
Where do we want to have the release announcement published? What kind
of message do we want to present in the release announcement? Who wants
to help write one?

* We could aim for Wednesday 30/09 for the release.

* Anything I didn't think of?



regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

I believe we still have community documentation that isn't updated.  
The least we should do is clearly mark them as

   "This document hasn't been verified with Grok 1.0 and may be  
outdated."

Preferably with an explanation on the community docs process and link  
to the Grok-doc information.

If we don't do this, it will reflect badly on the great work that has  
been done. I would argue that this is a show stopper.

Mvh Sebastian

On 27 sep 2009, at 23.01, Jan-Wijbrand Kolman wrote:

> Hi,
>
> The 1.0b2 has been out for a week or so. At the time of the release we
> thought we could do the final very soon after the beta. I'd still like
> to do that :-)
>
> A few questions:
>
> * So far there haven't been any showstoppers for a 1.0, right? If  
> there
> are, we should see if we can fix them.
>
> * It is not really a show stopper, it would be nice if someone  
> (Martijn,
> Uli?) could have a look at what I skethced out here:
>
> http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev
>
> See also the earlier "using zope.testbrowser to test for Unauthorized
> exceptions and updated zope.publisher with IReRaise exception support"
> thread.
>
> * Besides the regular release procedure, do we need to take extra  
> steps?
> Where do we want to have the release announcement published? What kind
> of message do we want to present in the release announcement? Who  
> wants
> to help write one?
>
> * We could aim for Wednesday 30/09 for the release.
>
> * Anything I didn't think of?
>
>
>
> regards,
> jw
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hi there,

Jan-Wijbrand Kolman wrote:

> * So far there haven't been any showstoppers for a 1.0, right? If there
> are, we should see if we can fix them.

I don't think anybody reported showstoppers.

> * It is not really a show stopper, it would be nice if someone (Martijn,
> Uli?) could have a look at what I skethced out here:
>
> http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev
>
> See also the earlier "using zope.testbrowser to test for Unauthorized
> exceptions and updated zope.publisher with IReRaise exception support"
> thread.

I took a look at it. How is exempt-exceptions configured?

I think this needs some documentation on when and how one would use it.

> * Besides the regular release procedure, do we need to take extra steps?
> Where do we want to have the release announcement published? What kind
> of message do we want to present in the release announcement? Who wants
> to help write one?

I hope someone has a list of places to mail to. If not, we're just going
to announce it to lwn.net besides the usual places. I'll also post an
entry in my blog.

I can help write a release announcement, though I don't have time until
tomorrow (the 30th).

> * We could aim for Wednesday 30/09 for the release.

This is fine with me, except I won't have time to write the announcement. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Sebastian Ware wrote:

> I believe we still have community documentation that isn't updated.  
> The least we should do is clearly mark them as
>
>    "This document hasn't been verified with Grok 1.0 and may be  
> outdated."
>
> Preferably with an explanation on the community docs process and link  
> to the Grok-doc information.
>
> If we don't do this, it will reflect badly on the great work that has  
> been done. I would argue that this is a show stopper.

So how do we resolve this situation? I'm fine with people marking the
documentation this way, but you need to organize an effort to do so,
right? Who is going to organize this?

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

If someone can tell me what the proper formating should look like (I  
am hopeless at ReST-formating) for text in a alertish-style box then  
I, Tim and Steve can mark docs as possibly outdated. I will be able to  
spend an hour on this tomorrow.

We obviously need help after that from people who could review these  
docs properly. Anybody who would can help with reviewing, just post  
your LaunchpadID and grok.zope.org username on the [Grok-doc] mailing  
list with a note that you want to check docs for 1.0 compatibility.

Mvh Sebastian

On 29 sep 2009, at 16.20, Martijn Faassen wrote:

> Sebastian Ware wrote:
>> I believe we still have community documentation that isn't updated.
>> The least we should do is clearly mark them as
>>
>>   "This document hasn't been verified with Grok 1.0 and may be
>> outdated."
>>
>> Preferably with an explanation on the community docs process and link
>> to the Grok-doc information.
>>
>> If we don't do this, it will reflect badly on the great work that has
>> been done. I would argue that this is a show stopper.
>
> So how do we resolve this situation? I'm fine with people marking the
> documentation this way, but you need to organize an effort to do so,
> right? Who is going to organize this?
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Sebastian Ware]

I have begun marking stuff as possibly outdated...

In the beginning of the document I inserted:

      **Might be outdated!** This document hasn't been reviewed for  
Grok 1.0 and may be outdated. If you would like to review the  
document, please read this post_.

.. _post: https://mail.zope.org/pipermail/grok-doc/2009-July/000002.html

In the blueprint I put:

   2009-09-30 == Marked as possibly outdated == /jhsware

Mvh Sebastian

On 29 sep 2009, at 16.50, Sebastian Ware wrote:

> If someone can tell me what the proper formating should look like (I
> am hopeless at ReST-formating) for text in a alertish-style box then
> I, Tim and Steve can mark docs as possibly outdated. I will be able to
> spend an hour on this tomorrow.
>
> We obviously need help after that from people who could review these
> docs properly. Anybody who would can help with reviewing, just post
> your LaunchpadID and grok.zope.org username on the [Grok-doc] mailing
> list with a note that you want to check docs for 1.0 compatibility.
>
> Mvh Sebastian
>
> On 29 sep 2009, at 16.20, Martijn Faassen wrote:
>
>> Sebastian Ware wrote:
>>> I believe we still have community documentation that isn't updated.
>>> The least we should do is clearly mark them as
>>>
>>>  "This document hasn't been verified with Grok 1.0 and may be
>>> outdated."
>>>
>>> Preferably with an explanation on the community docs process and  
>>> link
>>> to the Grok-doc information.
>>>
>>> If we don't do this, it will reflect badly on the great work that  
>>> has
>>> been done. I would argue that this is a show stopper.
>>
>> So how do we resolve this situation? I'm fine with people marking the
>> documentation this way, but you need to organize an effort to do so,
>> right? Who is going to organize this?
>>
>> Regards,
>>
>> Martijn
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev@...
>> https://mail.zope.org/mailman/listinfo/grok-dev
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> https://mail.zope.org/mailman/listinfo/grok-dev

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Martijn Faassen wrote:

>> * It is not really a show stopper, it would be nice if someone (Martijn,
>> Uli?) could have a look at what I skethced out here:
>>
>> http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev
>>
>> See also the earlier "using zope.testbrowser to test for Unauthorized
>> exceptions and updated zope.publisher with IReRaise exception support"
>> thread.
>
> I took a look at it. How is exempt-exceptions configured?

Like I In the debug.ini file for your grokproject, something like:

[app:zope]
use = egg:Debugging#debug
filter-with = translogger
exempt-exceptions = zope.security.interfaces.IUnauthorized,
                     some.other.interface.ISomething

Ofcourse, grokproject will generate one for you with the IUnauthorized
exempt already in there.

> I think this needs some documentation on when and how one would use it.

Sure, but I wanted some feedback on the approach first.

Do I understand that people generally agree on this approach? Surely we
need to document the behaviour, for example in the upgrade notes.


regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Martijn Faassen wrote:
> I hope someone has a list of places to mail to. If not, we're just going
> to announce it to lwn.net besides the usual places. I'll also post an
> entry in my blog.

Ok.

> I can help write a release announcement, though I don't have time until
> tomorrow (the 30th).

Could you write one today indeed. That would be very welcome.

regards,
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Jan-Wijbrand Kolman wrote:

> Martijn Faassen wrote:
>>> * It is not really a show stopper, it would be nice if someone (Martijn,
>>> Uli?) could have a look at what I skethced out here:
>>>
>>> http://svn.zope.org/grokcore.startup/branches/jw-configurable-ireraise-adaptation/?rev=104430&view=rev
>>>
>>> See also the earlier "using zope.testbrowser to test for Unauthorized
>>> exceptions and updated zope.publisher with IReRaise exception support"
>>> thread.
>> I took a look at it. How is exempt-exceptions configured?
>
> Like I In the debug.ini file for your grokproject, something like:
>
> [app:zope]
> use = egg:Debugging#debug
> filter-with = translogger
> exempt-exceptions = zope.security.interfaces.IUnauthorized,
>                      some.other.interface.ISomething
>
> Ofcourse, grokproject will generate one for you with the IUnauthorized
> exempt already in there.

I took a bit more context to figure out what this was about again. I
think a recap of the original problem and a few hints about the shape of
the solution would have helped put the whole problem into my mind again.


>> I think this needs some documentation on when and how one would use it.
>
> Sure, but I wanted some feedback on the approach first.
>
> Do I understand that people generally agree on this approach? Surely we
> need to document the behaviour, for example in the upgrade notes.

So here is my thinking process to try to figure out what this was about
again:

The original problem was that Unauthorized was not handled in zope
proper if the zope publisher was configured not to handle any exceptions
itself. This is bad in debug mode with WSGI. We added a modification so
we can configure the zope publisher not to reraise some exceptions like
Unauthorized if things are configured that way.

Now when you run functional tests this gives you a problem as you expect
Unauthorized to be there if you set handle_errors to false, but now it
isn't. Is that correct? I think that's a bug, as handle_errors to false
means we never want to handle any errors in the publisher, including
unauthorized. The tests should be run in a way so that when
handle_errors is False, the reraising behavior is turned off entirely.

Now somehow a feature to add to debug.ini those errors we don't want to
reraise helps with this issue. Why?

The missing idea in my mind is that we wouldn't configure this reraise
exception behavior in ZCML at all anymore. Instead we'd only put it in
debug.ini.

That sounds reasonable.

+1 for going ahead with that approach. Feel free to reuse some of the
above text for the documentation/upgrade notes.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Jan-Wijbrand Kolman wrote:

> Martijn Faassen wrote:
>> I hope someone has a list of places to mail to. If not, we're just going
>> to announce it to lwn.net besides the usual places. I'll also post an
>> entry in my blog.
>
> Ok.
>
>> I can help write a release announcement, though I don't have time until
>> tomorrow (the 30th).
>
> Could you write one today indeed. That would be very welcome.

Sorry, I got that wrong, I meant the day after tomorrow, which it is today.

I'll write some text and mail it to you.

Regards,

Martijn


_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev

[Jan-Wijbrand Kolman-3]

Martijn Faassen wrote:

>>> I took a look at it. How is exempt-exceptions configured?
>> Like I In the debug.ini file for your grokproject, something like:
>>
>> [app:zope]
>> use = egg:Debugging#debug
>> filter-with = translogger
>> exempt-exceptions = zope.security.interfaces.IUnauthorized,
>>                      some.other.interface.ISomething
>>
>> Ofcourse, grokproject will generate one for you with the IUnauthorized
>> exempt already in there.
>
> I took a bit more context to figure out what this was about again. I
> think a recap of the original problem and a few hints about the shape of
> the solution would have helped put the whole problem into my mind again.

Ah, ok, sorry for not providing enough context.

>>> I think this needs some documentation on when and how one would use it.
>> Sure, but I wanted some feedback on the approach first.
>>
>> Do I understand that people generally agree on this approach? Surely we
>> need to document the behaviour, for example in the upgrade notes.
>
> So here is my thinking process to try to figure out what this was about
> again:
>
> The original problem was that Unauthorized was not handled in zope
> proper if the zope publisher was configured not to handle any exceptions
> itself. This is bad in debug mode with WSGI. We added a modification so
> we can configure the zope publisher not to reraise some exceptions like
> Unauthorized if things are configured that way.

I'd rephrase that like so: The original problem was that when running
zope in debug mode with the WSGI evalexception middleware, zope is
instructed not to handle execeptions itself at all, including the
unauthorized.

This is bad, as the normal authentication mechanisms of zope then are
not triggered and as a result you cannot login.

We added a modification so that although zope was instructed not to
handle errors, to make an exception (no pun intended) for Unauthorized
to have this handled by zope after all (thus triggering authentication
mechanisms) - that's indeed done by telling zope not to re-raise this
particular type of errors.

> Now when you run functional tests this gives you a problem as you expect
> Unauthorized to be there if you set handle_errors to false, but now it
> isn't. Is that correct? I think that's a bug, as handle_errors to false
> means we never want to handle any errors in the publisher, including
> unauthorized. The tests should be run in a way so that when
> handle_errors is False, the reraising behavior is turned off entirely.

Exactly.

> Now somehow a feature to add to debug.ini those errors we don't want to
> reraise helps with this issue. Why?
>
> The missing idea in my mind is that we wouldn't configure this reraise
> exception behavior in ZCML at all anymore. Instead we'd only put it in
> debug.ini.

Right. We would remove the IReRaise adapter registration for
IUnauthorized from Grok's configure.zcml again. Instead, the factory
function that creates the zope WSGI app is instructed to register this
adapter for the types of exceptions that you do not want to have
re-raised in debug mode.

So, as a result, only in the case of using the debug.ini profile this
adapter is registered and in all other cases the exception handling
behaviour is just as it was before.

> That sounds reasonable.
>
> +1 for going ahead with that approach. Feel free to reuse some of the
> above text for the documentation/upgrade notes.

OK!

I'll try to work on this tonight and tomorrow to get this in properly fixed.

Thanks for reviewing.

regards
jw

_______________________________________________
Grok-dev mailing list
Grok-dev@...
https://mail.zope.org/mailman/listinfo/grok-dev