[Framework-Team] Re: Let sleeping PLIPs lie...

Wichert Akkerman wichert at wiggy.net
Tue Aug 22 20:12:27 UTC 2006

Previously Martin Aspeli wrote:
> Hi,
> >http://plone.org/products/plone/roadmap/117 (AJAX dep)
> >http://plone.org/products/plone/roadmap/116 (AJAX dep)
> >http://plone.org/products/plone/roadmap/163 (AJAX dep)
> >http://plone.org/products/plone/roadmap/124 (AJAX dep)
> All of these are fairly obvious. There will naturally be tweaking and 
> iterations of the implementation, but I think that these types of 
> improvements can sometimes be done on trunk rather than in branches 
> where they either would affect several other branches (e.g. a new widget 
> that several new features may need) or where they are straightforward 
> and/or easily reversible (e.g. a template change can be reverted without 
> serious dependency breakage).
> Let's see what does come in time for the deadline, but if some of these 
> don't, I'd be +1 to seeing them done afterwards *provided* that the beta 
> and RC deadlines are taken seriously!

They'll have to be done reasonably early in the alphas I think.

> Pragmatically speaking, as Limi points out, it's also a bit unfair to 
> penalise these PLIPs when we haven't got the AJAX story sorted out yet. 
> There is still too much uncertainty to start on any of these in earnest.


> >http://plone.org/products/plone/roadmap/176 (visual redesign pending)
> If this is too invasive, it may be a bit risky and impact a lot of other 
> PLIPs. If the changes are relatively minor or gradual, they may be OK. 
> This sounds like branch work, though. :)

It's incredibly vague so we can't judge this one. Do we have any idea
when this might start to become clearer?

> >A special one is:
> >http://plone.org/products/plone/roadmap/134 (too important to be 
> >dropped, needs champion - also relatively easy to do)
> We need a champion for this, badly. It's an important feature, and I've 
> seen a lot of users confused by the lack of editor/viewer local role 
> management on the sharing page. It's also relatively straightforward, it 
> just needs a person in charge. :-(

Code-wide it should be fairly low impact though, so it can be developed
on a branch or on a seperate product and merged when we feel it's ready.


Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

More information about the Framework-Team mailing list