Paul Winkler
2010-11-08 04:17:02 UTC
I've just updated the "bundle" (the pile of Zope Products that
fassembler puts in opencore/src/opencore-bundle), in order to get:
1) some Listen archive export fixes
2) a MailBoxer fix that allows it to work when the whole site is
served via https
3) some shell scripts that have long been in the bundle tarball but were
never checked in to SVN.
Having done that: I'm not really active in opencore development
anymore, except for the occasional little foray like this, but I gotta
say, I think the workflow for keeping the "bundle" updated is
terrible. In order to do make these updates you have to
1. make your updates or changes, and commit them - possibly in a
"vendor branch" (aka fork) if you don't have commit rights in the
original upstream repository.
2. update the svn:externals property on the opencore-bundle directory
itself, and make sure you get the revision numbers right.
3. remember to run the opencore-bundle/create-tarball.sh script
... which only works if you have permission to upload stuff to
svn.openplans.org/eggs ...
... and always bails out because MaildropHost/config.py always has
local changes because fassembler munges it on purpose, so you have
to temporarily revert that, then re-run the script, then put the
changes back in place.
If anybody stops after step 1, their local build now works as they
intended but all future builds will still get some old, presumably
broken code, in a place that's pretty obscure. In my experience, this
has happened a *lot*.
(I've just fixed the second problem with create-tarball.sh - it now
ignores changes to MaildropHost/config.py, which should be safe as
fassembler is always going to clobber that anyway. But the rest of the
issues remain.)
(There's also the problem that fassembler always gets the "current"
plone3-compatible bundle, whatever that happens to be; there's no way
for opencore-req.txt to specify anything more specific so you don't
really know what you're getting or which opencore releases it'll
actually work with. i.e. this part of the build is totally *not*
predictably repeatable)
Rant over!
P.S. Ethan, the svn:externals and script changes were applied to
https://svn.openplans.org/svn/bundles/opencore-plone30 in revisions
27886:27897 . You'll want to make the same changes on
svn.coactivate.org. Once that's done I can upload a new bundle to
svn.openplans.org/eggs so at least it has the right svn url... but
ideally fassembler and the create-tarball.sh script should be updated
to stop looking for it on svn.openplans.org/eggs.
fassembler puts in opencore/src/opencore-bundle), in order to get:
1) some Listen archive export fixes
2) a MailBoxer fix that allows it to work when the whole site is
served via https
3) some shell scripts that have long been in the bundle tarball but were
never checked in to SVN.
Having done that: I'm not really active in opencore development
anymore, except for the occasional little foray like this, but I gotta
say, I think the workflow for keeping the "bundle" updated is
terrible. In order to do make these updates you have to
1. make your updates or changes, and commit them - possibly in a
"vendor branch" (aka fork) if you don't have commit rights in the
original upstream repository.
2. update the svn:externals property on the opencore-bundle directory
itself, and make sure you get the revision numbers right.
3. remember to run the opencore-bundle/create-tarball.sh script
... which only works if you have permission to upload stuff to
svn.openplans.org/eggs ...
... and always bails out because MaildropHost/config.py always has
local changes because fassembler munges it on purpose, so you have
to temporarily revert that, then re-run the script, then put the
changes back in place.
If anybody stops after step 1, their local build now works as they
intended but all future builds will still get some old, presumably
broken code, in a place that's pretty obscure. In my experience, this
has happened a *lot*.
(I've just fixed the second problem with create-tarball.sh - it now
ignores changes to MaildropHost/config.py, which should be safe as
fassembler is always going to clobber that anyway. But the rest of the
issues remain.)
(There's also the problem that fassembler always gets the "current"
plone3-compatible bundle, whatever that happens to be; there's no way
for opencore-req.txt to specify anything more specific so you don't
really know what you're getting or which opencore releases it'll
actually work with. i.e. this part of the build is totally *not*
predictably repeatable)
Rant over!
P.S. Ethan, the svn:externals and script changes were applied to
https://svn.openplans.org/svn/bundles/opencore-plone30 in revisions
27886:27897 . You'll want to make the same changes on
svn.coactivate.org. Once that's done I can upload a new bundle to
svn.openplans.org/eggs so at least it has the right svn url... but
ideally fassembler and the create-tarball.sh script should be updated
to stop looking for it on svn.openplans.org/eggs.