[Framework-Team] Re: PLIP deadline overly aggressive?
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? -- Alexander Limi · http://limi.net ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limil...@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. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Alec Mitchell wrote: On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limil...@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. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On Mon, Jun 22, 2009 at 5:47 PM, Martin Aspelioptilude+li...@gmail.com wrote: Alec Mitchell wrote: On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limil...@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
[Framework-Team] Re: PLIP deadline overly aggressive?
Joel Burton j...@joelburton.com writes: I don't know what the discussion was like in deciding on this date. It may still be the right decision to have it end now. I'm just suggesting that, if it seems that quite a few people may think that this is a slightly-too-soon date, that you may benefit from having that conversation (sometimes, groupthink kicks in and everyone might be assuming this is too soon, but I'm the only person who probably thinks that, so no point bringing it up.) I've definitely been having some concern that valuable discussion might not have an opportunity to develop under the current deadline. Since I don't personally have a problem with this deadline, I haven't been saying much. Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Burton wrote: Hello, Framework Team! I, myself, don't have any questions or issues about the PLIP deadline for 4.0. I'm not planning on submitting any PLIPs. Over the past two weeks, though, while chatting in IRC with various framework team members and other core Plone people, at least 5 have mentioned, without my prompting, that the deadline for 4.0 PLIPs seemed awfully fast in coming, and they wondered whether it may have been too aggressive. I don't know what the discussion was like in deciding on this date. It may still be the right decision to have it end now. I'm just suggesting that, if it seems that quite a few people may think that this is a slightly-too-soon date, that you may benefit from having that conversation (sometimes, groupthink kicks in and everyone might be assuming this is too soon, but I'm the only person who probably thinks that, so no point bringing it up.) Just want to make sure that's not what happens. In any event, have a wonderful PLIP season! I look forward to teaching what you invent. ;) Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKPSyl+gerLs4ltQ4RAoVzAJ99H2Gz9+bEt1bRcrUwtN2RPSuU3gCfdDx1 lCfOg4/RoNHxBl22WuPxU/c= =hwMz -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On 20 Jun 2009, at 19:38, Tres Seaver wrote: Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. Hmm, the way I see it is that the timeline is deliberately short as 4.0 is an intermediate release. Trunk is the innovative, new thing, 4.0 is incremental upgrades that go beyond a 3.x release. In fact, the release was almost called 3.5 or similar. I don't know how I feel about this, the period is awfully short, but I'm probably leaning towards short keeps things from getting too ambitious. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Matthew Wilkes matt...@matthewwilkes.co.uk writes: On 20 Jun 2009, at 19:38, Tres Seaver wrote: Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. Hmm, the way I see it is that the timeline is deliberately short as 4.0 is an intermediate release. Trunk is the innovative, new thing, 4.0 is incremental upgrades that go beyond a 3.x release. In fact, the release was almost called 3.5 or similar. I don't know how I feel about this, the period is awfully short, but I'm probably leaning towards short keeps things from getting too ambitious. To clarify, I'm definitely on board with the spirit of moving quickly. My concern is that in moving quickly we'll end up missing discussion that needed to happen and that without that discussion we'll end up with a release that is technically short-sighted, demonstrates poor consideration of impacts to the wider community, or any other negative that can result from moving too quickly. So maybe we should re-phrase the question. How fast is *too* fast? What *are* the minimum requirements for discussion of a backwards incompatible major release? Ross ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On Sat, Jun 20, 2009 at 8:38 PM, Tres Seavertsea...@palladion.com wrote: Isn't 4.0 deliberately a short-hop release, with minimal new feautres, mostly intended to move the platform forward (to modern versions of Zope, Python, CMF)? Keeping the window short emphasizes that fact, at least to my outsider's eyes. We have a bit of a mismatch between the big plan and what just happened over the last weeks. The way Plone 4 has been schemed out, was indeed to be short-hop release, largely taking already completed work and packaging it up, so we could deliver something to our integrators and end-users while waiting for Plone trunk. What has been done so far, seemed to be largely in the way of baseline technology features, like Zope 2.12, Python 2.6 but also blob support, plone.folder and the various performance improvements in the content creation space. Now I take some blame and credit for the overall plan and I seem to have missed out one important point: our community. It seemed like we had an ever diminishing interest from our community to advance Plone itself over the course of the Plone 3.x timeline. The working assumption that I and others had, was that the current technological complexity of Plone, would cause this decline for a number of months or years. The hope was that after we refurbished some of our underlying technology to become less complicated, we would see a new rise in contributions. Given that idea, I think we have missed to ask our community at large for contributions and didn't give us a clear way to suggest these. Some of the ideas we have seen since the PLIP deadline has been opened are quite unfinished. However what completely positively surprised me was the amount of ideas and people that contributed already. It seems the Plone developer community is still much more alive and kicking than what at least I imagined. The tough call that is on the release manager and the framework team to make now, is how to best serve our community interest and come up with a roadmap that allows us to integrate all the exciting things that people suggested. One thing to remember is that continuously planning the road ahead is much more important than the plans we already made. Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Hanno Schlichting wrote: Personally I'd be in favor of extending the scope of Plone 4.0 to some degree and making a clear commitment to allow quite a number of the suggested features to be done in the scope of Plone 4.1, 4.2, ... releases. Much of the work that makes up Plone trunk (5.0?) today is going to take even more time than we had planned for and is all pretty invasive changes. If our developer community is still so much alive based on our current set of technologies, we can allow ourselves to take some more time to refurbish our backend. I think it's important to get 4.0 out the door quickly so we can start enjoying the benefits of Python 2.6, Zope 2.12 and CMF 2.2. With that in place we will be in a good position to add features in subsequent 4.x releases. So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1, you don't have to wait until 5.0. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP deadline overly aggressive?
On 20 Jun 2009, at 20:54, Laurence Rowe wrote: So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1 With the usual caveat that 4.x releases are as ambitious as 3.x releases. The reason we need a 4.0 release is so we can put the things Laurence mentions through. The place for ambitious changes is still trunk and PLIPs against 5. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP deadline overly aggressive?
Matthew Wilkes wrote: On 20 Jun 2009, at 20:54, Laurence Rowe wrote: So if your PLIP isn't ready now, don't worry. There'll be another chance to get it in with 4.1 With the usual caveat that 4.x releases are as ambitious as 3.x releases. The reason we need a 4.0 release is so we can put the things Laurence mentions through. The place for ambitious changes is still trunk and PLIPs against 5. I want to avoid a mad dash for getting features included with 4.0, so I'd like us to say that any PLIP we would consider for 4.0 we would also consider for subsequent 4.x releases. 4.0 is far less radical than 3.0, so I think we can safely spread out features throughout the 4.x line and not be quite as conservative as the 3.x changes have been. Laurence ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
