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.


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

ZopeSkel mailing list

Reply via email to