whit wrote:
> hey, if the werewolf wants to be on the framework team I say more the
> merrier ;)
+1 for having Martijn Faassen in the framework team.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo
Hi Hanno!
hannosch wrote:
> Added: plone.transforms/trunk/plone/transforms/interfaces/transform.py
> ==
> --- (empty file)
> +++ plone.transforms/trunk/plone/transforms/interfaces/transform.py Wed Jun
> 20 21:18:48 2007
Alexander Limi wrote:
>
>
> On Fri, 23 Mar 2007 05:00:45 -0700, Daniel Nouri wrote:
>
>> Do you want to tell (core) add-on developers to not make use of the
>> niceties
>> of plone.app.controlpanel because their thing is too complex?
>
> Uhm, if people can
Hi!
Alexander Limi wrote:
> - Archetypes
> - After we removed JS from checkboxes, they no longer "stick"
> (really!). Might have to put that back, even though it sucks
> - There's something strange going on with enabling comments, it
> only works on the init
Martin Aspeli wrote:
>
>
> Daniel Nouri wrote:
>
>>> This is probably a place where the buildout.cfg approach makes sense -
>>> we would be able to edit this file so that at any point in time it
>>> pointed at the right eggs to construct a Plone rele
Martin Aspeli wrote:
> Ian Bicking wrote:
>> If you use the easy_install script in the workingenv bin/, then you
>> don't have to activate the environment. Very similar to buildout,
>> workingenv scripts contain their path/environment.
>
> Right, thanks for pointing that out.
I should also menti
Hanno Schlichting wrote:
>
> Daniel Nouri wrote:
>> Hanno Schlichting wrote:
>>> Nope. Windows support for zopectl is a lot harder then just some path
>>> fiddling. But the real issue with it is not really something that is an
>>> argument for ploneout, I j
Hanno Schlichting wrote:
> Nope. Windows support for zopectl is a lot harder then just some path
> fiddling. But the real issue with it is not really something that is an
> argument for ploneout, I just took the time to implement it in it, it
> could be a separate package as well. The basic problem
Martin Aspeli wrote:
> Btw, can we move at least the Plone egg to svn.plone.org? I suggest
> svn.plone.org/svn/dist/Plone or something similar, since as you pointed
> out, /Plone may be a little confusing. If this really is to become a
> "meta-egg" with just dependencies, then I think something lik
I'm obviously for ploneenv/workingenv. I wouldn't have developed ploneenv
otherwise. So here is my pro-ploneenv reactions.
Martin Aspeli wrote:
> First of all, I think this is great. :) The important thing here is that
> people can use what they feel comfortable with - at the end of the day,
> a
ploneenv is a one module Python script that builds heavily on workingenv and
setuptools. What it does:
- It creates a Zope instance for you. You always provide the
``mkzopeinstance.py`` script that you want to use as an argument.
E.g.::
ploneenv ~/myzopeinstance \
--
Daniel Nouri wrote:
> Martin Aspeli wrote:
>> It is very interesting. What worries me a bit is how we eggify the
>> existing products. Perhaps we need a script to do that. It would almost
>> certainly introduce breakage of a lot of svn:externals, since the svn
>> lay
Martin Aspeli wrote:
> It is very interesting. What worries me a bit is how we eggify the
> existing products. Perhaps we need a script to do that. It would almost
> certainly introduce breakage of a lot of svn:externals, since the svn
> layout is different. We'd also depend on Zope (e.g. PAS) and
Kapil Thangavelu wrote:
> On Mon, 11 Dec 2006 08:55:07 -0500, Rocky Burt
> <[EMAIL PROTECTED]> wrote:
>
>> On Mon, 2006-11-12 at 13:43 +, Martin Aspeli wrote:
>>> Do people have opinions on this:
>>>
>>> http://plone.org/products/plone/roadmap/177
>>>
>>> It seems to be a very trivial patch to
I forgot another obvious problem:
- Should not depend on the user to have workingenv.py installed. The
script should download it if it's not there.
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo
Hello there!
I created a script install-plone.py that should help at least get an
idea of how the deployment of Plone 3.0 should look like.
Note that this is work in progress. I hope that people will help me
with figuring out the problems with this, and help me improve it.
You can download it f
whit wrote:
>> You could call it temporary in that Zope will hopefully get better at
>> development eggs and therefore render a weaved-together bundle like this
>> obsolete (instead, you'd have a bundle with eggs and then you'd
>> easy_install each one). To be honest, I find the bundle fairly
>
Martin Aspeli wrote:
> whit wrote:
>
>> my opinion is a little elbow grease to get this worked out now rather
>> than later would go a long way. eggs are bit of pain, but we don't
>> need to wait for any zope gods to descend from on high to make things
>> better.
>
> I agree in principle, I just
Offtopic:
Martin Aspeli wrote:
> - there needs to be a tiny bit of integration in CMFPlone when we
> merge. This will probably just be an ZCML statement in
> CMFPlone/configure.zcml to remove the need for the slug, and then a link
> somewhere in the Plone UI to @@manage-content-rules, which is t
whit wrote:
>
> ugh... could we devote a little time to packaging love here? maybe at
> the conference? This is tipping my suckometer.
>
> None of this is too fancy, but I think we've exceeded the utility of our
> bundle system and should fix our dev deploy story.
>
> some notes in this arena:
Hi!
Martin Aspeli wrote:
> Hi Daniel
>
>> From Saturday to Tuesday, I attended 4 days of presentation, discussion
>> and hands-on experience with KSS. First of all, thanks to Godefroid for
>> hosting a very nice sprint and to the whole team for the good time I had!
>>
>> I want to share some ex
Martin Aspeli wrote:
Alec Mitchell wrote:
Great analysis. I'm looking forward to my beer.
Wow, someone made it. :)
For me the big difference between these approaches is that one
requires changing many of the templates in Plone so that the rendered
results includes a bunch of fancy inline j
Martin Aspeli wrote:
> ...
> PLIP 179 - Improved commenting infrastructure
>
> There are three plips (120, 124 and 149) which have a CMFPlone but no
> bundle so I'm ignoring those.
>
>
> I think the markup (149) support basically works and is fairly low-risk,
> but it's also primaril
Hanno Schlichting wrote:
Daniel Nouri wrote:
Do you agree that we put the documentation in the top-level directory?
I.e. INSTALL.txt, README.txt etc. They shouldn't really go *inside*
the package I hear from Ian. Would also give us less duplication
between the plone_app and the plone
Wichert Akkerman wrote:
Previously Daniel Nouri said:
Do you agree that we put the documentation in the top-level directory?
I.e. INSTALL.txt, README.txt etc. They shouldn't really go *inside* the
package I hear from Ian. Would also give us less duplication between
the plone_app an
Hanno Schlichting wrote:
Hi.
As I'm lazy, I wrote a new template for plone.app projects now as well.
So in step 3 you can also do:
paster create -t plone_app
which will ask you the same question as the plone_core template but adds
a question for the second namespace, which defaults to app :)
Martin Aspeli wrote:
Daniel Nouri wrote:
whit wrote:
Martin Aspeli wrote:
Hi Hanno,
I'm happy to write the plone / plone.app announcement, and I can
write the bit about guidelines for when to use them. However, I'm
not too sure how we do the svn organisation.
- are we re
whit wrote:
Martin Aspeli wrote:
Hi Hanno,
I'm happy to write the plone / plone.app announcement, and I can write
the bit about guidelines for when to use them. However, I'm not too
sure how we do the svn organisation.
- are we recommending people use ZopeSkel?
cautious but enthusiastic no
Alexander Limi wrote:
On Wed, 26 Jul 2006 02:29:41 -0700, Daniel Nouri
<[EMAIL PROTECTED]> wrote:
-1 for plone / plone.cms as it is confusing ("heck, isn't all of Plone
for CMS 'functionality'?")
It might not be in the future. An example would be a dedicated
Alexander Limi wrote:
On Wed, 26 Jul 2006 02:29:41 -0700, Daniel Nouri
<[EMAIL PROTECTED]> wrote:
-1 for plone / plone.cms as it is confusing ("heck, isn't all of Plone
for CMS 'functionality'?")
It might not be in the future. An example would be a dedicated
Lo. Thanks for bringing this up...
+1 for plone / plone.app
-1 for cubed / plone, because 'plone' is a nice brand.
-1 for plone / plone.cms as it is confusing ("heck, isn't all of Plone
for CMS 'functionality'?")
Daniel
___
Framework-Team mailing li
Rocky Burt wrote:
> On Mon, 2006-01-05 at 19:20 -0700, Rob Miller wrote:
>
>>On May 1, 2006, at 4:19 PM, Rocky Burt wrote:
>>
>>
>>>On Tue, 2006-02-05 at 01:08 +0200, Hanno Schlichting wrote:
>>>
To summarize some of the discussion we had on IRC just now, here
is our
current idea, fo
32 matches
Mail list logo