Re: [Framework-Team] [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
2009/7/30 Erik Rose : >> 1) The current code base is located in the Collective. Since TinyMCE will >> be >> the default editor in Plone 4 should I move (copy) the code base to Plone >> SVN? > > -1. Why make it harder for people to contribute? By that argument, we'd have nothing in the Plone svn repository, and nothing covered by the contributor agreement. That's just silly. The contrib agreement and Foundation ownership are there for good reasons. Martin ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Minutes: 29 July 2009
Highlights from today's meeting -- * In order to quash the dependency on GroupUserFolder, we're unamimous in supporting upgrades only from >=2.5. 2.1 and earlier can take a detour through 2.5 to get to 4. * Talked in depth about Laurens' PLIP: showing full names instead of user IDs in user-visible places like bylines. We concluded that memoize backed by RAMCache is probably the best bet, but we would like to first see a simple (naive, cache-free) implementation and some benchmark numbers (pre- and post-implementation, ideally). Then we can decide, based on hard data, what caching (if any) to use. The Calliflower recording isn't up yet. To do -- Start thinking about which PLIP implementations you'd be well-suited to review. It's probably too soon to actually claim any, though, since we'd have to rebalance the load anyway once we know which 40% of them actually get implemented. Cheers, Erik Rose ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
1) The current code base is located in the Collective. Since TinyMCE will be the default editor in Plone 4 should I move (copy) the code base to Plone SVN? -1. Why make it harder for people to contribute? 2) I'm currently using the Products namespace for the package. Would it be better to switch to the plone(.app) namespace for Plone 4 (and keep the Products.TinyMCE for Plone 3)? -1. As Ross says, unless we have something to gain by changing it, let's not mess up people's imports, buildouts, etc. We can still change the license if we need to. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] today's meeting
On Jul 29, 2009, at 12:26 PM, David Glick wrote: ... * PLIP handoffs. What sort of info do we expect from PLIP authors when they submit their PLIPs? For my 3.3 PLIPs I did a writeup like http://svn.plone.org/svn/plone/review/plip240-locking-improvements/PLIP_240_README.txt ...now that I'm in the reviewer's chair I'd certainly find it helpful to have this sort of information from others. That's definitely something I'd like to see us continue. Any qualms about including this information as a comment in the PLIP ticket? Eric ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] today's meeting
On Jul 29, 2009, at 1:03 PM, Hanno Schlichting wrote: On Wed, Jul 29, 2009 at 6:26 PM, David Glick wrote: A couple things I'd like to talk about: * Upgrade policy. Currently Plone 3 supports migrations from Plone <= 2.0.5. I was hoping to be able to do that for Plone 4 as well, but there is a tradeoff. Plone 4 no longer has any runtime dependency on GroupUserFolder, so I was hoping we wouldn't need to depend on it any longer. However, it is still needed in order to migrate Plone sites from before we used PAS (e.g., Plone < 2.5). I think we have 2 options: Thoughts on which is preferable? 3. What about supporting upgrades from Plone 2.5 final and later? These sites all have PAS installed already. Since 2.5 is considered a "major" version, we would still support the upgrade from the last two "major versions" of Plone instead of one. 2.5 also introduced GenericSetup, and with an upgrade machinery depending on GS it is easier to have that in place before any upgrade. I'm comfortable with that. I've only attempted it once, but the 2.0.x - > 3.x migration I've done needed a pass through a 2.5 instance to work properly anyway. * wicked / AdvancedQuery. See https://dev.plone.org/plone/ticket/ 9398 ...Does removing this dependency make sense? Is someone willing to volunteer to make the needed change in wicked? I think the change makes sense. AdvancedQuery was only accidentally included as a dependency of wicked and never got a proper risk analysis. With Dieter Maurer now essentially gone and as far as I know no longer doing any Zope development, we don't have any chance of updating AdvancedQuery to silence all the deprecation warnings for 2.12. I can take that on. I It's time I got my hands dirty instead of sitting back and letting David do all of the fun stuff. ;) ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] today's meeting
On Wed, Jul 29, 2009 at 6:26 PM, David Glick wrote: > A couple things I'd like to talk about: > * Upgrade policy. Currently Plone 3 supports migrations from Plone <= > 2.0.5. I was hoping to be able to do that for Plone 4 as well, but there is > a tradeoff. Plone 4 no longer has any runtime dependency on > GroupUserFolder, so I was hoping we wouldn't need to depend on it any > longer. However, it is still needed in order to migrate Plone sites from > before we used PAS (e.g., Plone < 2.5). I think we have 2 options: > Thoughts on which is preferable? 3. What about supporting upgrades from Plone 2.5 final and later? These sites all have PAS installed already. Since 2.5 is considered a "major" version, we would still support the upgrade from the last two "major versions" of Plone instead of one. 2.5 also introduced GenericSetup, and with an upgrade machinery depending on GS it is easier to have that in place before any upgrade. > * wicked / AdvancedQuery. See https://dev.plone.org/plone/ticket/9398 > ...Does removing this dependency make sense? Is someone willing to > volunteer to make the needed change in wicked? I think the change makes sense. AdvancedQuery was only accidentally included as a dependency of wicked and never got a proper risk analysis. With Dieter Maurer now essentially gone and as far as I know no longer doing any Zope development, we don't have any chance of updating AdvancedQuery to silence all the deprecation warnings for 2.12. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] today's meeting
A couple things I'd like to talk about: * Upgrade policy. Currently Plone 3 supports migrations from Plone <= 2.0.5. I was hoping to be able to do that for Plone 4 as well, but there is a tradeoff. Plone 4 no longer has any runtime dependency on GroupUserFolder, so I was hoping we wouldn't need to depend on it any longer. However, it is still needed in order to migrate Plone sites from before we used PAS (e.g., Plone < 2.5). I think we have 2 options: 1. Get rid of the GroupUserFolder dependency from PlonePAS, but require it for the new plone.app.upgrade package. That way it's at least possible to avoid loading the extra code when running normally, but it can still be added for upgrading (and would be included by default with the installers, presumably). The downside is that we would still depend on GroupUserFolder from the migration, so would still need to maintain it at least nominally to make sure that it runs well enough in Zope 2.12 to extract data from it. 2. Declare that upgrades to Plone 4 are only supported from Plone 3 or greater. So if you have a Plone 2.0.5 site, say, you would first install and upgrade to Plone 3 (which would take care of migrating the user folder), then install and upgrade to Plone 4 (which would no longer require any GRUF dependency). Thoughts on which is preferable? * wicked / AdvancedQuery. See https://dev.plone.org/plone/ticket/ 9398 ...Does removing this dependency make sense? Is someone willing to volunteer to make the needed change in wicked? * PLIP handoffs. What sort of info do we expect from PLIP authors when they submit their PLIPs? For my 3.3 PLIPs I did a writeup like http://svn.plone.org/svn/plone/review/plip240-locking-improvements/PLIP_240_README.txt ...now that I'm in the reviewer's chair I'd certainly find it helpful to have this sort of information from others. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@onenw.org work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] today's meeting
A couple things I'd like to talk about: * Upgrade policy. Currently Plone 3 supports migrations from Plone <= 2.0.5. I was hoping to be able to do that for Plone 4 as well, but there is a tradeoff. Plone 4 no longer has any runtime dependency on GroupUserFolder, so I was hoping we wouldn't need to depend on it any longer. However, it is still needed in order to migrate Plone sites from before we used PAS (e.g., Plone < 2.5). I think we have 2 options: 1. Get rid of the GroupUserFolder dependency from PlonePAS, but require it for the new plone.app.upgrade package. That way it's at least possible to avoid loading the extra code when running normally, but it can still be added for upgrading (and would be included by default with the installers, presumably). The downside is that we would still depend on GroupUserFolder from the migration, so would still need to maintain it at least nominally to make sure that it runs well enough in Zope 2.12 to extract data from it. 2. Declare that upgrades to Plone 4 are only supported from Plone 3 or greater. So if you have a Plone 2.0.5 site, say, you would first install and upgrade to Plone 3 (which would take care of migrating the user folder), then install and upgrade to Plone 4 (which would no longer require any GRUF dependency). Thoughts on which is preferable? * wicked / AdvancedQuery. See https://dev.plone.org/plone/ticket/ 9398 ...Does removing this dependency make sense? Is someone willing to volunteer to make the needed change in wicked? * PLIP handoffs. What sort of info do we expect from PLIP authors when they submit their PLIPs? For my 3.3 PLIPs I did a writeup like http://svn.plone.org/svn/plone/review/plip240-locking-improvements/PLIP_240_README.txt ...now that I'm in the reviewer's chair I'd certainly find it helpful to have this sort of information from others. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@onenw.org work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On Wed, Jul 29, 2009 at 9:47 AM, Martin Aspeli wrote: > Wichert Akkerman wrote: > >> The whole point of the agreement and the conservatory is that we have a >> solid legal basis. I would really like to see an informed legal opinion on >> the requirements for moving existing code to foundation ownership. Without >> that I fear we may be on dangerous ground and risk making the separate >> repository useless. +100 For what I know we needed to explicitly state what code we had written and wanted to donate to the Foundation for work done prior to the agreement. We do need some kind of document (whatever constitutes a legal document in Delaware) that states who transfers what code to the Foundation. Just because I signed the agreement to transfer the my rights in the stuff now in the Plone repo, doesn't mean I automatically transfer the copyright in anything else. > But don't let it stop or discourage people from doing what's right. The > Contributor Agreement is pretty clear reading, especially the front page > matter: http://plone.org/foundation/contributors-agreement/agreement.pdf The first thing you learn about the legal system is that the written text of any agreement or contract is just a tiny little piece of what actually is the case. What is written might be clearly illegal, it might not match current law practice as exercised by courts anymore or the text might look like it's stating something whereas the legal language makes it something else. Legal language and English only seem to be the same for some degree, but they aren't really. > People get far too worked up over the What Would A Layer Do question, > probably in the belief that there is in fact a black-and-white answer that > they're just not qualified to know. I can understand it coming from > Americans. They probably have wristbands with that written on them. Less so > from the Dutch. :) There's never a black-and-white answer. But with American case law you have no clue whatsoever what could be the case without studying a lot of law. Since we have pro-bono legal council, we better make use of it for important legal concerns. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
Wichert Akkerman wrote: The whole point of the agreement and the conservatory is that we have a solid legal basis. I would really like to see an informed legal opinion on the requirements for moving existing code to foundation ownership. Without that I fear we may be on dangerous ground and risk making the separate repository useless. If someone has the time to do this and it doesn't cost anything, go ahead. But don't let it stop or discourage people from doing what's right. The Contributor Agreement is pretty clear reading, especially the front page matter: http://plone.org/foundation/contributors-agreement/agreement.pdf People get far too worked up over the What Would A Layer Do question, probably in the belief that there is in fact a black-and-white answer that they're just not qualified to know. I can understand it coming from Americans. They probably have wristbands with that written on them. Less so from the Dutch. :) 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: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On Wed, Jul 29, 2009 at 12:34 AM, Wichert Akkerman wrote: > The whole point of the agreement and the conservatory is that we have a > solid legal basis. I would really like to see an informed legal opinion on > the requirements for moving existing code to foundation ownership. Without > that I fear we may be on dangerous ground and risk making the separate > repository useless. Geir, if this is not territory that's been covered before, would you be willing to ping David Powsner about it? :jon ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
Wichert Akkerman wrote: On 7/29/09 7:51 AM, Jon Stahl wrote: On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarn wrote: There is a step missing here: contributors must not only have signed the agreement, they must explicitly allow that specific code to be donated to the foundation. Signing the contributor agreement does not mean all your code can be moved at will to the foundation. Yes, of course. Implied but omitted. My bad. Thanks. So, my question is: what qualifies as "explicit" agreement? Does it have to be "on the permanent record" in some manner? You'll have to ask the PF legal counsel I'm afraid. I don't know the right answer. I suspect you don't need to ask. :) If all contributors of all lines of code that are being moved consent, and have signed the contributor agreement, then there really is no issue. We're now getting into a technical argument about what constitutes "consent", but it's hardly that difficult. You ask. They say yes or no. An email trail would be nice. In reality, whenever we deal with these kinds of things, we operate within some margin of acceptable risk. A risk always has a probability of occurring and a probable impact if it does occur. The acceptability of a risk depends on these two factors. Equally, there's a (usually more measurable) cost and sometimes other risks associated with doing nothing. So, in this case, we're deciding whether to move a product into the PF repository. There are risks and costs associated with not doing this, that is, the usual risks to Plone associated with code not covered by the agreement. There are risks associated with going ahead with the move, such as: - Rob may lie about some contributor having consented - Rob may misinterpret a particular response as consent - Someone may indicate consent and then lie about it later, pretending they didn't consent, and try to raise hell - We may have it all wrong, and it may turn out there is some convoluted legal procedure we *have* to follow, and if we don't, men in expensive suits are going to come after us The probability of any of those occurring I'd say is very low. The impact would also likely be very low if any of these things did occur. Most likely, the worst that would happen is that the PF board would need to discuss it for a bit. In the worst case, we move the code back to the Collective. Let's try not to use the "we're not lawyers" argument as self-censorship stop energy. The reality is that there's a big grey zone that we all operate in every day, whether we are aware or not, and in reality the spirit of the contributor agreement and the conservancy model matters infinitely more than the technical details. Furthermore, I suspect if you asked two lawyers, you'd get at least two different answers. Of course - I'm not a lawyer. But I do deal with these kinds of questions quite often over commercial matters where there is a lot more at stake than there is here, and a much higher probability of actual, quantifiable losses if important steps are missed. 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: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On 7/29/09 8:09 AM, Martin Aspeli wrote: Jon Stahl wrote: On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarn wrote: There is a step missing here: contributors must not only have signed the agreement, they must explicitly allow that specific code to be donated to the foundation. Signing the contributor agreement does not mean all your code can be moved at will to the foundation. Yes, of course. Implied but omitted. My bad. Thanks. So, my question is: what qualifies as "explicit" agreement? Does it have to be "on the permanent record" in some manner? In our business, an email that you keep tends to be enough. I would: - Ask the relevant people by email - Ask them to reply by email giving explicit consent - Store those emails "forever" - Make a note in a CONTRIBUTORS.txt or similar that these people consented on a particular date If that's ever in dispute, you can go back to those emails. I don't see a reason for any kind of "wet signature" so long as they've signed the contributor agreement. We're not *trying* to be difficult. :) The whole point of the agreement and the conservatory is that we have a solid legal basis. I would really like to see an informed legal opinion on the requirements for moving existing code to foundation ownership. Without that I fear we may be on dangerous ground and risk making the separate repository useless. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor
On 7/29/09 7:51 AM, Jon Stahl wrote: On Tue, Jul 28, 2009 at 12:07 AM, Geir Bækholt · Jarn wrote: There is a step missing here: contributors must not only have signed the agreement, they must explicitly allow that specific code to be donated to the foundation. Signing the contributor agreement does not mean all your code can be moved at will to the foundation. Yes, of course. Implied but omitted. My bad. Thanks. So, my question is: what qualifies as "explicit" agreement? Does it have to be "on the permanent record" in some manner? You'll have to ask the PF legal counsel I'm afraid. I don't know the right answer. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
