On 5/11/06, Martin Aspeli <[EMAIL PROTECTED]> wrote:
On Thu, 11 May 2006 03:03:17 +0100, Hanno Schlichting
<[EMAIL PROTECTED]> wrote:
> Hi again.
>
>> From what I have read so far, we tend into the direction of giving this
> release a bit more time. So here is an updated roadmap proposal. The one
> thing it tries to be is realistic about the dates if we allow more time
> for development of new features and therefore bugs as well and get the
> busy x-mas time in our way.
>
> Plone 3.0
> ---------
> June 26, plip freeze (no more plip's are accepted)
Do we have such a thing? I mean ... people can write PLIPs whenever they
want :)
Actually I think an early PLIP freeze and an initial PLIP review is a
very good idea. It will encourage developers to fully form and
document their ideas before going off half-cocked with an
implementation. It will allow you guys to have a peek into the
implementation ideas, offer some guidance in that area (probably not
formally as the FT, but it's likely that some of you will be
interested/disgusted enough in some proposals that you may want to
offer some advice), and possibly veto some proposals that don't make
much sense from a high-level perspective before too much time has been
sunk into their implementation. IIRC, there was a PLIP freeze for
2.5, and though our phone meetings often went a bit off track during
that period, it was valuable IMO. This may also accomplish some of
the goals that Martin seems to be concerned with.
> August 21, proposal freeze (review bundles must be ready)
> September 25, feature freeze (all features have been merged)
> October 22, first beta release
> December 18, first release candidate
> January 24, expected release
Do we have any understanding of how long it took us to jump through those
hoops for 2.5 (at least from alpha to beta, etc. and what our projections
are))? Or for 2.1? I think the interim time steps look reasonable, but
it's hard to judge how long it actually takes to get enough testing and
coding time.
This schedule seems very reasonable to me, and is just a suggestion
for the release manager who will need to tailor it based on the actual
details of the accepted proposals.
P.S. I think Hanno makes an important point in another post that the
members of the FT should not have to be people concerned with the
details of the "future" of plone in the way that Martin and limi so
clearly are. I, personally, think that those things tend to work
themselves out in a number of different ways without the need for
rigid structures or formal bodies(either from semi-formal declarations
at sprints (a la limi), or via individual encouragement of existing
projects, or with funding from from an organization which needs a
particular feature, or even just through the persistent work of a
motivated developer).
Alec
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
