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.
Maurits
_______________________________________________
ZopeSkel mailing list
ZopeSkel@lists.plone.org
http://lists.plone.org/mailman/listinfo/zopeskel
