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 term.

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.


Chris Calloway
office: 332 Chapman Hall   phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599

ZopeSkel mailing list

Reply via email to