Hey,
all looks good to me.
My only comment regards this
Release Candidate cycle :
bug squashing from feedback,
fix migration bugs,
possibly small new features.
I'd avoid putting in small new features into an RC and just get it out
and work on those small features in 0.4.
Cheers.
And.
On 06/02/2009, at 2:47 PM, andy nicholson wrote:
Hi
Trollfot and I were talking in irc about the development /
installation
methodology . from plone 3.2 , buildout is going to be the main way
plone distributes itself, as python eggs. So we can probably consider
soley targeting that method for new installs of plumi 0.3 - not the
old
way of installing separately from sources, for each component. ie
download Zope src, Plone version, then products into a special folder.
Buildout is managing these dependencies for you, downloading eggs from
the network, we just need to have all our dependencies ported over to
this system.
The buildout UI is here
http://plumi.org/browser/plumi-buildout-plone3/trunk
svn url is:
https://svn.engagemedia.org/project/plumi-buildout-plone3/trunk
The buildout is currently using the 'Plumi' codebase repository , to
pull in the old style Plone 2.5 products
(ATVideo/ATEngageVideo/PlumiSkin etc)
This file, at the very bottom shows this:
http://plumi.org/browser/plumi-buildout-plone3/trunk/devel.cfg
The Plumi codebase repository Im talking about here , is the now
plone 3
compatiable, but still in non-python-egg format:
http://dev.plone.org/collective/browser/Plumi/trunk/EXTERNALS.txt
ie the trunk of 'Plumi', using that 'svn:externals' attributes on the
trunk directory itself to download the dependencies via svn, when you
check out a copy.[ its managed through this 'EXTERNALS.txt' file for
convenience, a common technique, check the comments at the top for svn
commands to check the folder/file in sync. ]
Because of the buildout changeover, plone plugins are changing into
eggs, and hence their location, slowly , in SVN, from being part of
the
'svn:externals' inside the 'Plumi' codebase :
http://dev.plone.org/collective/browser/Plumi/trunk/EXTERNALS.txt
to being inside the buildout.cfg conf file in the buildout code base,
'plumi-buildout-plone3' . This is to be listed for downloaded from the
network as a python egg, whenever the buildout process is run:
http://plumi.org/browser/plumi-buildout-plone3/trunk/buildout.cfg
Example
The vaporisation product, in plumi 0.2.x , is listed as an
'svn:external' downloading a tag of the plone 2.5 compatible Product,
inside the 'Plumi' folder in the plone collective:
http://dev.plone.org/collective/browser/Plumi/branches/plumi-0.2.x/EXTERNALS.txt
Now, in the python egg way, vaporisation is distributed in that
fashion,
inside buildout which knows about eggs, and slotting them via zcml
into
plone 3.
IE See the 'buildout.cfg' for plumi 0.3 , now in the
'plumi-buildout-plone3' code base:
http://plumi.org/browser/plumi-buildout-plone3/trunk/buildout.cfg
[ Vaporisation isnt (yet) on pypi (a public listing of eggs,
http://pypi.python.org/pypi/ ) so I have checked it out into the
buildout project's 'src' directory, meant for local egg development,
using a svn tag release.
http://plumi.org/browser/plumi-buildout-plone3/trunk/src
a...@tebet:/opt/tebet-instances/plumi3.engagemedia.org$ svn info
src/vaporisation/
Path: src/vaporisation
URL:
http://svn.plone.org/svn/collective/Vaporisation/tags/vaporisation-egg-2.0.1
]
I have remove portletification altogether from plumi 0.3, on advice
from
trollfot. Not need anymore.
I will start doing changeover into the new Plone 3 style, for
plumi.app / plumi.skin, modules already started for new Plumi dev
ie they arent in egg form yet in svn.
I will then see how feasible it is to try to get all the products from
the old style 'EXTERNALS.txt' Plumi codebase into the new
buildout.cfg.
If we can do that, then, apart from the all the docs (*.txt files)
inside that 'Plumi' codebase, we can stop using that codebase, since
we
will have all our products/dependencies managed via eggs. Eg either
inside 'src' , managed via an 'EXTERNALS.txt' approach again, or
uploaded to pypi.
Alpha release:
I think we could release the alpha after doing the above, and after
any
tickets on the trac also for this milestone. No migrations of old
plumi
sites working at all for alpha.
Beta Release :
would then be adding back functionality, and at least a migration
approach sort-of working, bug fixing.
Release Candidate cycle :
bug squashing from feedback,
fix migration bugs,
possibly small new features.
0.4 -- new features,
old code base Products removed totally,
new version of indytube
There is a fresh new plumi 0.3 site to play with :
http://tebet.engagemedia.org:9080/plumitest4/
--
Andy Nicholson
http://wiki.infiniterecursion.com.au/wiki/ContactDetails
_______________________________________________
Discuss mailing list
[email protected]
http://lists.plumi.org/listinfo/discuss
_______________________________________________
Discuss mailing list
[email protected]
http://lists.plumi.org/listinfo/discuss
