Op 15-03-10 23:28, Cristopher Ewing schreef:
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.
/me puts on his Poi maintainer hat. :-) (For the record, I don't mind if zopeskel starts using a different tracker; that is up to the main developers.)

You can edit the issue and add a tag 'upstream' to it. The tags are clickable from the main tracker page, which could be enough for this use case.

I wonder if 'postponed' may be the best workflow state for these kinds of tickets, basically saying: "Yes, it is a bug, but no we are not going to work on it anytime soon."

As for this issue, I do not use the --svn-repository argument myself; when you create a package, paster creates that egg-info directory and this will also end up in subversion, which should never be the case. From the traceback it does not look like we can easily change something in zopeskel to avoid this error when creating a buildout. So for better or worse this indeed looks like an upstream issue.


ZopeSkel mailing list

Reply via email to