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.
-- Sincerely, Chris Calloway http://www.secoora.org office: 332 Chapman Hall phone: (919) 599-3530 mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599 _______________________________________________ ZopeSkel mailing list ZopeSkel@lists.plone.org http://lists.plone.org/mailman/listinfo/zopeskel