Previously Martin Aspeli wrote:
> Wichert Akkerman wrote:
> > We need to get Plone 3.2 and 3.3 on the road. Contrary to previous 
> > releases I am not going to produce a complete schedule for the whole 
> > release process this time around - we've seen too often that those 
> > schedules keep changing anyway. Instead I'll keep planning the next two 
> > steps in the process for each release.
> 
> That sounds like a good idea.
> 
> > Lets start with Plone 3.2. This release will be a maintenance release 
> > for Plone 3.x in all aspects except packaging technology: it will be 
> > fully egg based. The first two steps for this release are:
> > 
> >     * egg releases of all components ready before October 1st
> >     * first alpha release during the Plone Conference
> 
> 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.

> > For Plone 3.3 we will start with a round of PLIP previews, during which 
> > the framework team can provide a verdict on the desirability of proposed 
> > PLIPs. The criteria are correct technical design, correct user interface 
> > design, and the need merge the PLIP in core instead of maintaining or 
> > maturing it as an add-on. The dates are:
> > 
> >     * PLIPs to be submitted before October 5th
> >     * framework team gives verdict on all PLIPs before October 20th
> 
> I assume this is about PLIPs in principle, rather than code/bundles?
> 
> I think we need to give people a bit more time if we're talking about 
> code, especially since we want people to help with the 3.2 work (and 
> testing!) as well.

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.

> > The planning is geared around the Plone conference; I am hoping that the 
> > framework team will be able to take schedule one or more discussions 
> > there to discuss these PLIPs, if possible with the PLIP authors present.
> 
> That's a good idea. On the other hand, I wonder if it would be nice to 
> give people a chance to come up with and work on PLIPs during the 
> post-conference sprint. In the past, we've seen a spike in PLIPs around 
> sprints as people focus on one thing or another.
> 
> I think it'd make sense if the current Framework Team could decide 
> whether they'd prefer to have the PLIP deadline, say, on the Friday 
> following the conference (October 17th) with this in mind, or if they 
> would benefit more from having time to discuss PLIPs at the conference 
> and thus keep the deadline for the 5th.

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.

Wichert.

-- 
Wichert Akkerman <[EMAIL PROTECTED]>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to