Hi Wichert,
We also need to determine what we do with existing eggs that have
dodgy/missing dependencies, and whether or not we can make
plone.recipe.plone optional (or just a dumb wrapper around zc.recipe.egg).
We already have some suggestions and discussion on that and I have a
local git tree which tries to solve a lot of this. I'll commit that back
to svn after my vacation in a few weeks.
Cool! I think we need to decide if we want to go with the KGS route that
Zope are using, the index route that repoze is using, a recipe route
like we have now, or something else.
This is not about code at all, it is about deciding early on if the
PLIPs are desirable and correct so we can immediately inform the PLIP
authors. I don't want people working very hard at a PLIP when we already
know that it will not be accepted or that it will need to be changed.
Cool - that's what I thought. +1 for that.
There is always a reason to wait for another date. I think a lot of
people are coming up with ideas while preparing / psyching up for the
conenference, so this schedule makes sense to me.
Sure, I can see it either way. However, I think the Framework Team
should make the decision here, since this review step is almost entirely
down to them. If none of them will have time or see themselves working
on this during the conference, then we can make better use of the
conference time to allow PLIPs to foster.
Personally, I'm leaning slightly in the direction of waiting for PLIP
submissions until after the conference. There'll be several talks about
and opportunities to discuss ways to improve Plone. If someone has a
good idea and wants to PLIP it (and better yet, work on it) during the
conference/sprint, telling them that the window is closed would be a shame.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
