[Framework-Team] Reworking the PLIP Lifecycle | discussion

[Alec Mitchell]

On Thu, Feb 24, 2011 at 10:36 AM, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Thu, Feb 24, 2011 at 3:26 AM, Elizabeth Leddy <eleddy at umich.edu> wrote:
>> Feel free to respond over email or just edit the
>> document: http://dev.plone.org/plone/wiki/PlipProcess
>
> Great work!

Agreed!  This has the potential to greatly improve our process and
provide the larger community of developers and users with a more
certainty about how and when things are happening in the shadowy world
of framework decisions and release management.

>> In general, I'd like to give the fixed release schedule a 6 month test
>> drive. If it sucks we can go back to status quo or move forward with the
>> latest and greatest.
>
> I cannot remember any Plone releases that only took 6 months - even
> when we tried hard. I'd usually expect a 50% overrun from any stated
> timeline, so while aiming for 6 months we can manage to do a release
> after 9 months. We'd have to aim for a 3-4 months cycle to actually be
> able to do two releases in a year.
>
> And I wouldn't really want to do more than two releases per year, or
> we risk getting too fragmented, diverging code bases and very short
> support lifecycles for each release (only the last 4.x release gets
> bugfixes at any given time according to our current policy).
>
> I think we could aim for a spring and an autumn release, expecting
> most people to be busy in summer vacations and around x-mas/new year.

I agree strongly with this.  A 3 month cycle seems really ambitious.
While ambition may be a good thing here, we need to think about the
consequences of such a short cycle.  This could drastically shorten
the support lifetime of any given release.  Is that something we
really want to do?  It could also put a huge burden on release
managers with respect to minor/bugfix releases (especially if we
decide to support more of these 3-month releases at a time).  We might
be better off with the more realistic and practical goal of trying to
achieve a true 6-month cycle.

It seems likely that this process will require a also larger "team"
for any given release (particularly given the historic attrition rate
of team members over the course the review process), along with a
reasonable mechanism for members to opt-out of a particular cycle if
needed.

Alec