[Framework-Team] Re: PLIP deadline overly aggressive?

Alec Mitchell apm13 at columbia.edu
Tue Jun 23 01:11:04 UTC 2009


On Mon, Jun 22, 2009 at 5:47 PM, Martin Aspeli<optilude+lists at gmail.com> wrote:
> Alec Mitchell wrote:
>>
>> On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limi<limi at plone.org> wrote:
>>>
>>> On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli
>>> <optilude+lists at gmail.com>
>>> wrote:
>>>
>>>>  - We use this PLIP review cycle to start assigning PLIPs to 4.1.
>>>> There's
>>>> no reason we can't and shouldn't start planning for that now. So, if a
>>>> PLIP
>>>> looks like it'll take longer to do, we can still vote +1 in principle,
>>>> but
>>>> target it for a 4.1 release that can come not too long after 4.0 is out.
>>>
>>> I agree strongly on this. A process note, I see we have created 4.1, 4.2
>>> milestones — would it be better to create a 4.x milestone like we did on
>>> 3.x, so we can say "it'll be in one of the 4.x releases" instead of tying
>>> it
>>> to a specific release until we actually know which release it'll make it
>>> into?
>>
>> I'd say this may be premature.  There are going to be PLIPs which
>> require a break with backwards compatibility, and which only make
>> sense for 4.0.  Those we have to assess on their desirability and
>> feasibility.  If they seem too radical they would be pushed to 5.0.
>>
>> Then there are the less ambitious PLIPs which don't require
>> significant changes to add-ons, customizations or documentation.  If
>> we determine that the change is desirable, it would potentially be
>> acceptable for any release in the 4.x series.
>>
>> In that case, what is the purpose in explicitly pushing it into a
>> later release in the cycle?  Making that decision could discourage the
>> development of the feature entirely.  If the PLIP developers feel that
>> they can have the feature ready in the specified timeline, and we feel
>> that it is a beneficial change for Plone, arbitrarily pushing it to a
>> later release seems inappropriate.
>>
>> If the PLIP developers themselves indicate that they may not have
>> enough time for development, such a decision may make sense.  This
>> could easily be the case for developers who have submitted multiple
>> high quality PLIPs.  Beyond that, I don't see how we can make an
>> objective determination of which features are not right for 4.0 but
>> are fine for 4.1.
>>
>> If we are going to be assigning PLIPs to future 4.x releases, I think
>> we need to have some clear guidelines on which to base such decisions.
>
> I agree that we should defer this decision if we can. But also consider that
> each PLIP takes a fair amount of effort to review at each stage. In the
> past, the framework team has become a bottleneck as they've had to review
> more-than-expected PLIPs. Then we have a merge bottleneck and the potential
> for more bugs introduced during the merge process, which drags the release
> out further. For example, will all those "almost ready" add-on products work
> flawlessly on Zope 2.12? We don't know yet.
>
> I'm not saying we should defer things by default, and the BBB argument is
> very important w.r.t. going into a .0 release. I'm just suggesting we keep
> the option on the table to say "yes please, but we need to wait a little bit
> longer".

I understand the purpose it would serve, but on what basis would we
make such a determination?

Alec




More information about the Framework-Team mailing list