On Sat, Jun 20, 2009 at 12:17 PM, Martin Aspeli<optilude+li...@gmail.com> wrote:
>> - c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to
>>  double check whether this requires a migration for any persistent  objects,
>> and write that if necessary
> +0 to remove.

There's no persistent stuff based on that particular class since Plone
2.1. What is still left is the OrderedContainer implementation inside
the PloneFolder module, as this is used by the PloneSite object
itself. This ought to be cleaned up since OFS has almost the same
implementation, but this is a different task.

The temporary folder used for the FactoryTool was based on this as
well, but can use the PortalFolder from CMF instead. It's just faking
some more rich environment to create a new content object in and
luckily never persisted.

>> - c20337, c20338, c22979, c22981, c22988 - switch the control panel to  be
>> based on normal actions in a new action category, rather than using  a
>> special control panel tool (hannosch) — see also
>> http://dev.plone.org/old/plone/ticket/8804
> +0 - we need to make sure the existing controlpanel.xml import step
> continues to work.

There's an extra PLIP for this for Plone 5. Especially since I figured
out that actions in their current form are the most critical
performance bottleneck we have by a large margin, I don't want to move
anything to actions at all anymore. I'd leave these changes out until
we have figured out what to do with actions in general instead. Moving
more actions to the actions tool will make things slower if we don't
include some of the workarounds and hacks I did to the actions
machinery all over.

>> - c22831, c22832, c22891, c22951 — remove external editor (hannosch) —
>>  see http://dev.plone.org/old/plone/ticket/8592
> -0 - people do use this. what's the cost of keeping it?

See the ticket for details. It has an extra ticket and needs
discussion, so better leave it out for now. The main argument is that
it's unmaintained for ages and not used by many. It's a perfect add-on

>> - c22847 — remove wicked from core (hannosch) — see
>> http://dev.plone.org/old/plone/ticket/8593  (but note that as of this week
>> Carsten Senger has been doing some  maintenance...yay!)
> +0 to make this an add on people can install if they need it, but we should
> endeavour to make it work for migrated sites

This has an extra ticket as well and I'd leave it out of the other
changes. There's at least documentation to be done here if we remove
it from the core.

>> - c23193 — turning default_error_message into a browser view  (hannosch) —
>> seems like a decent idea to me, but as implemented here  it removes the
>> redirector and content search features
> +0 - I think ideally plone.app.redirector should just override this view and
> do nothing if not explicitly installed. I'm not sure we have time to do that
> properly, though.

I wouldn't touch this. The main reason for these changes are, that the
old way of doing things doesn't work in the repoze.zope2 / WSGI world.
Exception views, standard_error_message, the error_log and all that
stuff simply doesn't work at all. So the whole of p.a.redirector needs
to be changed quite a bit to be made to work in that new world. Since
WSGI is out of the scope for 4.0, I'd leave these things out for now.

>> - c23198, c23199 — removal of portal_interface tool (hannosch) — if we
>>  remove this then we lose the way to check for marker interfaces from
>>  action expressions, for instance. also, it's missing a migration
> +0 to remove. Doesn't plone.app.layout.globals have something for this
> that's based on a view rather than a tool?

I'd leave this in place, but then it needs to be changed to work with
zope.interface interfaces instead of Interface stuff. Removing this
was made under the assumption that there's no skin templates / scripts
left in default Plone that would need this. This won't be the aim for
Plone 4.0, so this thing might still have some legitimate use.

>> - c23226, c23233 — moving migrations to plone.app.upgrade and using  all
>> GS without the migration tool (hannosch) — -0 from me...I think  moving
>> these to a separate package may actually make it harder to keep  migrations
>> in sync with the Plone release they belong too, simply from  the standpoint
>> of reviewing svn history
> +1 to move to all GS, at least. I don't have a strong feeling about the
> package location. Maybe Hanno does?

The initial driver for making this into its own package, was that the
upgrade steps tend to have dependencies on quite a number of add-ons,
like CMFEditions, KSS, portlets, ... for interfaces or to call into
code to make some changes. If the Plone distribution itself contains
the migration code, it gets all these dependencies pulled in and makes
it quite hard to create a "minimal base distribution". The way I
attacked the "unclutter dependencies / base distribution" problem is
based on the assumption that the Plone distribution itself turns into
a no-code, policy distribution of some kind in the end, so all code
moves out of the package over time. Based on that direction it made
sense to move the upgrade stuff out of the package, since I had to
change and re-arrange it entirely anyways to match the new
GenericSetup based approach.

>> - c23337 — Removed strangely implemented users search from the users
>>  folder (hannosch) — I didn't look carefully enough yet to see whether  this
>> is a good idea or not :)
> Strangely implemented users search, ey? ;-)

That's also known as the Members folder roster. This is part of
removing all default content from the base installation.

>> - c23343 - Removed initial content from default installation  (hannosch) —
>> This probably does belong in a profile in a separate  package that is
>> included by the standard installers.  But creating  that hasn't been done
>> yet.
> -0 - I think Plone needs to ship with some default content. Where it lives I
> don't care.

Well, I really hate having default content around, that I have to
delete all the time and people use in tests that later on break if we
change it. The initial content just won't make sense for many sites
and people waste huge amount of times to try to get the initial
content to match some form of uber-use-case. Has anyone looked at how
much time people spent of fixing the nested "past events" collection?
Except that everyone really thinks that nested collections are a bad
idea in general and they actually don't really work? And then we have
the infamous "front-page" which welcomes our users to Plone 3.0 with
the exact same message up until today? We don't update these things
and there's no one driving it. I'd just rather have something be part
of the installers that welcomes new users and points to some section
on plone.org for continuously updated information. An updated guide on
plone.org about "Your first steps with Plone - how to create content"
and a "How to organize your content (simple information architecture)"
stuff would be more helpful and allow users to feel in charge of the
content in their site. Right now first time users can't really tell,
if those initial folders are content or part of the application logic
and won't dare to change them. Not to mention that they create hard
problems in multi-lingual settings, where you actually want to layout
your site quite differently. So +1 one a "welcome screen" that isn't
content in itself but a big -100 on any content in a new site. That's
what demo.plone.org would be for.

>> - Consolidating the skin directories into just plone_browser,
>>  plone_resources, and plone_images....plus moving 3rd party javascripts  to
>> plone.app.javascript. — I'm -0 on this.  Keeping the old layout  would make
>> it easier to merge things from the 3.x branch; switching to  the new layout
>> would make it easier to merge from trunk.  Keeping the  old layout has the
>> advantage of not obsoleting a lot of existing  documentation, and not
>> changing something that we think there's a good  chance we'll change again
>> in 5.0 when we hopefully have a better  unified Zope 3 vs. CMF skinning
>> story.
> -0 - I agree with you. I think we should tackle this by getting rid of skins
> altogether. :p

Yep, this doesn't make sense until we remove all of them. I'll
probably just revert those changes on trunk as well to make merging
easier in the meantime. Once an entire folder is empty, we can remove

>> - Archetypes c8430 — return unicode encoding by default (hannosch) —  My
>> charset and encoding fu is weak.  Is this what we want?
> +1 to make Plone all unicode, all of the time. I defer to Hanno, though.

There's quite a number of interesting implications with this, for
example what is getting cataloged and if everything in the catalogs
needs to be migrated, not to mention all code that had been written to
deal with the current situation. For Plone 5 this makes perfect sense
to do, for 4.0 this is a potential can of worms and I'd personally not
try it. This change will avoid quite a number of Unicode errors in a
lot of places where we need to explicitly deal with them right now.
But it will introduce errors into places where we haven't seen them
before. Given that we have almost no Unicode-driven test coverage for
any functionality, these things will only be found by users and have
quite a large potential bad marketing effect. I'd advise not to try
this on a fixed and limited time schedule.

>> - The current situation with regard to PlacelessTranslationService  needs
>> to be reviewed to make sure that our language negotiator and  product i18n
>> dirs are still getting registered properly following  simplification/removal
>> of Five's Zope2 i18n integration layer.  Hanno  said he could probably take
>> a look at this.
> Let's hold him to that. ;)

This should be quite simple, as I told David in a private mail already
and I'm going to look into this.

>> - I switched back to Zope 2.12.0b1 for now because with Zope 2.12.0b2
>>  there is an issue preventing the Unauthorized error when you first try  to
>> access the ZMI from getting propagated into an HTTP authentication  request.
>>  I haven't had time to dig into this yet although I did check  a non-Plone
>> Zope 2.12.0b2 and it didn't seem to be an issue there.
> Weird. Maybe to do with our force migration of the root acl_users to PAS?

There's maybe something in the GRUF/PAS part that I changed to deal
with this, which hasn't been adjusted yet. Exception handling is both
very different in Python 2.6 (no string exceptions anymore) as well as
repoze.zope2, so there might also be some kind of new problem.

>> - We need to make plone.recipe.zope2instance work with an eggified  zope.
>>  Currently it doesn't know where to find the mkzopeinstance  script or other
>> skeleton configuration.  I made a quick hacky branch  to make my dev
>> buildout work, but this needs some more careful work.
> Do we? I thought we could basically get away without an instance at all (but
> then where do we put 'Extensions' and 'import'?), just depending on the
> right things and generating a zope.conf and a startup script? I haven't
> looked into it, though.

We need an instance of some sort to have a place for the zope.conf and
site.zcml and start/stop script for one. Since we want to support ZEO
and the http port of the webserver is in the zope.conf file, we need
the ability to have multiple instances. Since we will need to change
quite a bit of that stuff when WSGI hits, I'd rather try to mimic the
current behavior / layout as closely as possibly for 4.0, so we don't
invalidate the documentation twice.


Framework-Team mailing list

Reply via email to