Chris, Thanks for the input. I appreciate your guidance as I get used to managing a process like zopeskel.
On Mar 15, 2010, at 3:13 PM, Chris Calloway wrote: > The ticket can simply document what the upstream problem is. By leaving it > open with that documentation, it can provide a pointer to how to ultimately > resolve the issue, should anyone be interested in doing so. Closing the > ticket just makes it more unlikely paster will get fixed. I'm not saying > keeping it open makes it more likely. It's just that closing it does make it > less likely. > I'm good with that. I've been trying to come to some general idea for my own satisfaction of when I can tag and release new versions, and my thought was that using 'confirmed' status in the issue tracker as a state for tickets I wanted to clear before releasing would be one way of making a sort of goalpost for myself getting new releases out. I wish that there was a way to have an 'upstream' tag or state for tickets so that we could leave them open, confirmed as being real, but also say 'the problem is not in our code, but in this other package'. Unfortunately I don't see a way to do that in POI. Might be a reason to move to a more flexible trac instance, but I'm not going to push for that yet. In any case, I can agree with your reasoning, and your conclusions. I'll leave the tickets open as I find them. > Also, this may be more of an abuse issue on our part. Paster was created to > create eggs, not buildouts. It has a right to expect egg-info. This issue > might be telling us something. 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. c ******************************** Cris Ewing Webmaster, Lead Developer Department of Radiology Web Services University of Washington School of Medicine Work Phone: (206) 616-1288 Cell Phone: (206) 708-9083 E-mail: cew...@u.washington.edu Web: http://www.rad.washington.edu ******************************* _______________________________________________ ZopeSkel mailing list ZopeSkel@lists.plone.org http://lists.plone.org/mailman/listinfo/zopeskel