headers
Eric Steele | 1 Jul 2009 01:01
Picon
Gravatar

Re: Having Hanno around


On Jun 30, 2009, at 6:27 PM, Hanno Schlichting wrote:

> On Wed, Jul 1, 2009 at 12:10 AM, Eric Steele<ems174@...> wrote:
>> I'd asked him about this early on in the process, his response was  
>> basically
>> that he'd rather not and he looked forward to removing everything  
>> we'd done
>> when Plone 5 rolled around.
>
> I hope you didn't take that seriously. What I meant was: I trust the
> framework team to make good decisions based on what they know today.
> There might be some future plans which aren't yet communicated in a
> way that even the framework team members know about them. Those should
> not influence the fwt decisions, as they are essentially vaporware at
> this point.

Yeah, I forgot the winky emoticon there...

> I tried to give some feedback directly on plip's I felt my input would
> change the output in some way. If there's concrete questions that came
> up, I'm more than happy to answer them.
>
>> It wouldn't hurt to ask again, though.
>
> Now that I finally moved back home and have settled in to a new place
> with reliable wifi, I'd be able to attend some phone calls I'd guess.
> If you feel that would bring any benefit, I'd be happy to join.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Steele | 1 Jul 2009 17:07
Picon
Gravatar

[Plone 4] Zope 2.12 status

David,

I completely forgot to ask about your migration progress yesterday  
during our meeting. Would you mind giving us a quick update on where  
you stand? Any blockers that we could help you with?

Thanks,
Eric
Permalink | Reply | 5 comments |
headers
David Glick | 1 Jul 2009 20:33

Re: [Plone 4] Zope 2.12 status

On Jul 1, 2009, at 8:07 AM, Eric Steele wrote:
> I completely forgot to ask about your migration progress yesterday  
> during our meeting. Would you mind giving us a quick update on where  
> you stand? Any blockers that we could help you with?

My todo list looks something like this:

- track down and resolve the remaining 11 test failures in CMFPlone
- start testing the other packages (and probably merging some more  
things for them)
- finish making plone.recipe.zope2instance work for eggified zopes
- sort out PloneFolder situation (it can probably go but I need to  
confirm that)
- sort out actions API change (Hanno changed the way you fetch an  
action category on trunk; I haven't had a chance to look closely and  
figure out what the risks are yet)
- sort out action icon changes
- sort out plone.app.upgrades
- sort out GRUF/PAS changes (on trunk Hanno removed the GRUF  
dependency and moved the tools to PlonePAS...I need to figure out how  
risky this is)
- sort out KSS (actually this is already partially sorted out, I'm  
just waiting on commit access to codespeak)
- sort out use of Globals and other deprecation warnings
- sort out javascript stuff (on trunk Martijn and Roel moved this to  
plone.app.javascript, I need to look more closely)
- sort out image traversal stuff / linkintegrity (image scales are now  
found via an IPublishTraverse adapter rather than __bobo_traverse__,  
which doesn't work during non-publish traversal, so linkintegrity  
fails to detect that images are linked in a document)
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Glick | 1 Jul 2009 21:22

Re: Re: [Plone 4] Zope 2.12 status

On Jul 1, 2009, at 12:13 PM, Hanno Schlichting wrote:
> As a general comment, it might be that selectively trying to backport
> my stuff won't necessarily be the quickest way forward anymore.
> Especially ones you hit stuff I did later on, it all moves to
> dependency reduction and speedups, which aren't required to get the
> stuff running on Zope 2.12. Working from the unittests / TTW-testing
> until stuff works is another way to do it.

Yep, I've already shifted mostly into this mode.

>> - sort out PloneFolder situation (it can probably go but I need to  
>> confirm
>> that)
> I think I responded to that already... it can go, as its only used
> indirectly by the temporary folder from portal factory and some tests.
> Or you let it stay. It doesn't matter much, as it's so little.

Yeah, you did, I just haven't had a chance to deal with it yet.

>> - sort out actions API change (Hanno changed the way you fetch an  
>> action
>> category on trunk; I haven't had a chance to look closely and  
>> figure out
>> what the risks are yet)
>
> I'd stay away from those. There's quite a number of evolutionary
> changes made over time. The end result as seen today on trunk is
> nowhere near what I'd consider to be finished. This is really a
> separate change. Even in its minimal version it requires
> backwards-incompatible API changes, that currently aren't documented.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hanno Schlichting | 1 Jul 2009 21:13
Picon
Gravatar

Re: Re: [Plone 4] Zope 2.12 status

Hi.

As a general comment, it might be that selectively trying to backport
my stuff won't necessarily be the quickest way forward anymore.
Especially ones you hit stuff I did later on, it all moves to
dependency reduction and speedups, which aren't required to get the
stuff running on Zope 2.12. Working from the unittests / TTW-testing
until stuff works is another way to do it.

Keep in mind that the scope is about getting Plone running on Zope
2.12 and CMF 2.2, not about backporting all my craziness ;)

On Wed, Jul 1, 2009 at 8:33 PM, David Glick<davidglick@...> wrote:
> My todo list looks something like this:
>
> - track down and resolve the remaining 11 test failures in CMFPlone
> - start testing the other packages (and probably merging some more things
> for them)
> - finish making plone.recipe.zope2instance work for eggified zopes
> - sort out PloneFolder situation (it can probably go but I need to confirm
> that)

I think I responded to that already... it can go, as its only used
indirectly by the temporary folder from portal factory and some tests.
Or you let it stay. It doesn't matter much, as it's so little.

> - sort out actions API change (Hanno changed the way you fetch an action
> category on trunk; I haven't had a chance to look closely and figure out
> what the risks are yet)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andreas Zeidler | 2 Jul 2009 00:25
Picon
Favicon
Gravatar

Re: Re: [Plone 4] Zope 2.12 status

On Jul 1, 2009, at 9:22 PM, David Glick wrote:
> On Jul 1, 2009, at 12:13 PM, Hanno Schlichting wrote:
>>> - sort out image traversal stuff / linkintegrity (image scales are  
>>> now found
>>> via an IPublishTraverse adapter rather than __bobo_traverse__,  
>>> which doesn't
>>> work during non-publish traversal, so linkintegrity fails to  
>>> detect that
>>> images are linked in a document)
>>
>> Huh? I thought that change was only part of Archetypes trunk and not
>> in the scope of Plone 4.
>
> I haven't given a lot of attention to Archetypes yet.  We can (and  
> probably should) exclude that change.

otoh, `plone.app.imaging` also introduces that adapter, and as it was  
mainly created as a support package for adding "image support" to  
`plone.app.blob` (did you think anyone wanted those configurable image  
scales? :)).  that's because the latter overrides the original adapter  
with an implementation based on zodb blobs.

so i'm gonna argue for it's inclusion into plone 4, thereby bringing  
back the `IPublishTraverse` adapter.  of course, limi simply converted  
that old PSPS ticket (#7822) into a PLIP and i didn't think of adding  
a reference to that dependency, so the fwt will have a point in  
turning this down.  i should mention, though, that not being able to  
rely on `plone.app.imaging` would set back "image support" quite a bit  
and thereby reduce the chances of wrapping up blob support in time.   
also, i think the configurable image scales have been a popular
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hanno Schlichting | 2 Jul 2009 10:57
Picon
Gravatar

Re: Re: [Plone 4] Zope 2.12 status

On Thu, Jul 2, 2009 at 12:25 AM, Andreas Zeidler<az@...> wrote:
> On Jul 1, 2009, at 9:22 PM, David Glick wrote:
>>
>> On Jul 1, 2009, at 12:13 PM, Hanno Schlichting wrote:
>>>>
>>>> - sort out image traversal stuff / linkintegrity (image scales are now
>>>> found
>>>> via an IPublishTraverse adapter rather than __bobo_traverse__, which
>>>> doesn't
>>>> work during non-publish traversal, so linkintegrity fails to detect that
>>>> images are linked in a document)
>>>
>>> Huh? I thought that change was only part of Archetypes trunk and not
>>> in the scope of Plone 4.

This should have read: Not in the scope of David's PLIP.

>> I haven't given a lot of attention to Archetypes yet.  We can (and
>> probably should) exclude that change.
>
> otoh, `plone.app.imaging` also introduces that adapter, and as it was mainly
> created as a support package for adding "image support" to `plone.app.blob`
> (did you think anyone wanted those configurable image scales? :)).  that's
> because the latter overrides the original adapter with an implementation
> based on zodb blobs.
>
> so i'm gonna argue for it's inclusion into plone 4, thereby bringing back
> the `IPublishTraverse` adapter.  of course, limi simply converted that old
> PSPS ticket (#7822) into a PLIP and i didn't think of adding a reference to
> that dependency, so the fwt will have a point in turning this down.  i
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raphael Ritz | 2 Jul 2009 13:53
Gravatar

#9310 got a baby (#9347)

Hi,

responding to our comments Duco has just broken
out the user registration policy part from PLIP #9310
into #9347. So we have now

http://dev.plone.org/plone/ticket/9310
"User registration process more flexible"
only covering flexible member data and

http://dev.plone.org/plone/ticket/9347 
Registration policy
to cover the other aspect.

The new PLIP shows up on
 http://dev.plone.org/plone/roadmap
and on our spread sheet where we keep
track of the voting (first one currently).
I've also added our plip-advisory list to the
cc of the ticket and assigned it to Duco.

Hope that's it. Now we can start considering
these two proposals separately.

Thanks for the prompt action Duco!

Raphael
Permalink | Reply | 0 comments |
headers
Alec Mitchell | 2 Jul 2009 18:52
Favicon

Combining Search Results PLIPs

Hello Geir and Laurens:

Both of your search results PLIPs (9271, 9282) were approved by the
Framework Team for inclusion in Plone 4.0.  However, all voters
expressed a strong preference that the two PLIPs and the effort to
implement them be merged.  It would not be acceptable to have two
competing implementations of the same feature(s) submitted for code
review.  It is essential that you open a discussion and work together
to merge your efforts.  Please keep the Framework Team apprised of the
results of your discussion by re-submitting a single combined PLIP
ASAP.

Thank you,
Alec Mitchell
Permalink | Reply | 2 comments |
headers
Alec Mitchell | 2 Jul 2009 20:16
Favicon

Re: Combining Search Results PLIPs

Would it be acceptable if we simply marked one of those PLIPs as
invalid then?  Which one would be preferable?  Enjoy your vacation
Geir.

Alec

On Thu, Jul 2, 2009 at 11:10 AM, Geir Bækholt · Jarn<baekholt@...> wrote:
> I am on my way to vacation with my family, and cannot do anything until
> Monday at the earliest.
> I have discussed the search results improvements with Laurens before he
> submitted his, and the two plips are accidental. They are 95% the same plip.
> I'll coordinate and make sure there will not be 2 implementations. - but if
> the plips have to be merged before Monday, someone else needs to do it.
> (feel free). Sorry abut the delay.
>
> --
> Geir Bækholt
> (iPhone)
>
> On 2. juli 2009, at 18.52, Alec Mitchell <apm13@...> wrote:
>
>> Hello Geir and Laurens:
>>
>> Both of your search results PLIPs (9271, 9282) were approved by the
>> Framework Team for inclusion in Plone 4.0.  However, all voters
>> expressed a strong preference that the two PLIPs and the effort to
>> implement them be merged.  It would not be acceptable to have two
>> competing implementations of the same feature(s) submitted for code
>> review.  It is essential that you open a discussion and work together
>> to merge your efforts.  Please keep the Framework Team apprised of the
(Continue reading)

Permalink | Reply | 0 comments |

Gmane