On 3/15/2010 6:28 PM, Cristopher Ewing wrote:
A lot of the issues that jaroel opens seem to fall into this territory. In
fact, this whole process of doing svn checkins while creating your code
skeleton seem to point to a bunch of assumptions that are hard-coded in paster.
If that means that paster is a tool that is too specific to a particular use
case to fit as our base, I'm not totally surprised. I think we've edged around
the discussion of how suitable paster is as a core for zopeskel for a while
now. Let's see where these issues lead us, and that's a discussion we can have
more of going forward.
I was going to suggest that would be one more reason to keep upstream
issues open; but stopped short thinking I'd said enough.
As the upstream open tickets accumulate, I'm sure they are going to
provide more evidence that we are just abusing the hell out of paster,
as we've discussed many times.
Having these open tickets might just eventually provide us with some
clue about what kind of tool we need to implement ZopeSkel properly.
Before the sprint, we went to Ian for commit access to paster in case
there was anything we felt we urgently needed to fix in order to get our
work done. Not only was he glad to grant us to that access, he kind of
begged us to take paster over. We decided not to get stuck with that, as
the larger issue seemed to be should we even be using paster in the long
Of course, having trac instead of Poi is just one more reason why we
want ZopeSkel to become a peer with Plone and Archetypes with its own
repository instead of a Collective product susceptible to drive-by code.
office: 332 Chapman Hall phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599
ZopeSkel mailing list