Alexander Limi wrote:
Hi Alex,
actually I was trying to make a slightly different point
and using those PLIPs for illustration more than anything
else.
Let me try differently:
When discussing the developer add-ons now we see questions like
"Is it OK to include/recommend PDBDebugMode in there or is
it too intrusive?"
Again, I don't want to discuss this particular question here
but rather the fact whether the Framework Team should get
engaged in deciding this at all.
Reason being that we are crossing a line here because
we're not considering to include PDBDebugMode (to stick
to the example) in the core distribution (it won't get
there - period) but a recommendation on a specific
3rd-party add-on.
And while the general question "Should we support some
sort of developer pack?" seems to see a lot of support
(in fact we have it already) the questions are at least
also in those details.
Or again differently put:
When we review code for inclusion in Plone core we try
hard to make sure certain requirements are fulfilled.
Should we apply the same standards to those recommended
add-ons? (jQ tools, Amberjack, various dev packages)
Does that mean that we take on responsibility for
judging their quality above and beyond their usefulness
to us?
For me that makes a difference. While I feel comfortable
about the dev add-ons because I know (most of) them from
using them myself I would have a hard time figuring out
anything serious and reliable about Amberjacks standing.
And I admit right away that I'm far from being a
JS/jQ/jQT expert in order to judge whether this is the
best recommendation we could give. Yet I'm asking myself
whether I should care at all.
Again, I don't want to discuss any of those PLIPs specifically
here. I'd rather like to bring up the question that arises
from the possibilities we have now to distinguish between
"Plone core (the code)" and "Plone the distribution" (what
you get through the installers - directly or indirectly).
So far my understanding has been that the FWT is concerned
with the former (the code) but some of our current PLIPs
bring up the latter (the distribution). This is why I'm
asking what people consider the scope of the FWT to be.
Personally, I'm fine either way but I'd like us to know
what we are doing.
(Or maybe I'm just biased by being too deep in science and
politics in my day job that I see issues were there are none ..)
Raphael
> On Wed, 01 Jul 2009 07:47:48 -0700, Raphael Ritz
> <
[hidden email]> wrote:
>
>> First, let's look at some PLIPs and their rational:
>>
>>
http://dev.plone.org/plone/ticket/9250:>> "We propose to include the jQuery Tools library in
>> the base Plone install." -> one reason being to
>> give recommendations to people what to use when
>> doing advanced JQ stuff
>
> The intention was also to start using this in Plone core. We need a
> solution for the problems that jQuery Tools solve (modal dialogs, for
> one), and currently we have no standard solution for this. It's a bit like
> saying "implement your own file picker" in an operating system, it's a bad
> idea to not have a standard that everyone can use.
>
>>
http://dev.plone.org/plone/ticket/9314:>> "Provide in the installers an installation option
>> [..] to load a common development environment."
>> -> give recommendation on what 3rd-party add-ons
>> to use while developing
>
> I think having the installers have the option to install dev tools
> (disabled by default) is the same as having them commented out in the
> standard buildout. I don't see a problem here.
>
>>
http://dev.plone.org/plone/ticket/9324:>> "We propose using Amberjack to create [these]
>> guided tours for people new to Plone."
>> -> give recommendation on what 3rd-party tool
>> to use to support a certain feature
>
> I think this is a "must have" for Plone if we're going to solve the
> largest usability problem we have now: "what to do next". Installing Plone
> is now something that works great for people 99% of the time, so next up
> is solving the discoverability problem of how to use Plone.
>
> The reason I proposed putting this in the installers only, was to avoid
> having the "but I don't want that in core Plone" for the people that
> deploy Plone for their customers. You shouldn't have to disable it
> explicitly when you create your own deployment, and it's not a hard
> dependency. But I really think it's a core requirement to not lose all the
> people that install Plone and then don't know what to do — which is very
> common according to our uninstall feedback.
>
>
------------------------------------------------------------------------------
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
