On Mon, Jun 22, 2009 at 5:47 PM, Martin Aspeli<optilude+li...@gmail.com> wrote: > Alec Mitchell wrote: >> >> On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limi<l...@plone.org> wrote: >>> >>> On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli >>> <optilude+li...@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 _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team