Sent this from the wrong address so it got bounced :-/ ---------- Forwarded message ---------- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 16 Jan 2008 13:36 Subject: Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204 To: [EMAIL PROTECTED]
You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at [EMAIL PROTECTED] ---------- Forwarded message ---------- From: "Martin Aspeli" <[EMAIL PROTECTED]> To: "Raphael Ritz" <[EMAIL PROTECTED]> Date: Wed, 16 Jan 2008 13:36:10 +0000 Subject: Re: [Framework-Team] Re: Official submission: PLIP 184, 200, 203 and 204 Hi Raphael, > While the particular issue is fixed now I don't think this > discussion is entirely moot. I agree with Wichert here > that we cannot have things breaking simply because > people have an add-on installed. > In the particular case it was even worse than I first thought > because having FCKeditor installed also broke the kupu > formlib widget even for people that had kupu selected > as personal preference. So I correct my initial classification > >from boarder line to show stopper. > > Why am I saying this now that the issue is fixed? > Because I want us to be careful when doing code review > and remind us that we promised to not break 3rd-party > products in this release. (here it was a lack of extensibilty > actually) > > Furthermore, I also agree with Wichert in that we need to > look at this from a user's and not a developer's perspective. > I don't want to tell my users "You know this is a new feature > that unfortunately breaks with your current configuration > but it wasn't available before anyway ...". > > What's more: the issue is more central then it might seem > at first glance as it is not about WYSIWYG editing a static > portlet only but about providing a WYSIWYG widget for > *all* formlib based forms which we will see increasingly > often in the future. Having such a widget not honoring the > current customizability (after all we do offer to select the > editor in the personal preferences) would have been a > major flaw. I definitely agree with all of this. I would say that when reviewing bundles and making merge/don't-merge decisions, we should focus mainly on "plain Plone", but obviously use our judgement in terms of the risk to third party products. If it were up to me, not fixing this issue until after bundle acceptance or even after merge would be OK - no different from another hard-to-foresee bug with a third party product that's appropriate to fix in alpha/beta phases. This also lessens the burden of reviewers: imagine having to test every bundle with every third party product. ;-) Martin _______________________________________________ Framework-Team mailing list [email protected] http://lists.plone.org/mailman/listinfo/framework-team
