+1 on sandbox testing for grok releases.<br><br><div class="gmail_quote">On Tue, Apr 22, 2008 at 3:16 PM, Wichert Akkerman <<a href="mailto:wichert@wiggy.net">wichert@wiggy.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Previously Ethan Jucovy wrote:<br>
> Peter,<br>
><br>
> This is a bug in a bugfix release of z3c.autoinclude that I stupidly<br>
> released on the same day as the new grok release. See<br>
> <a href="http://mail.zope.org/pipermail/grok-dev/2008-April/004561.html" target="_blank">http://mail.zope.org/pipermail/grok-dev/2008-April/004561.html</a> -- I'm on it<br>
> and will hopefully have it fixed shortly.<br>
<br>
</div>Even so I thought grok was using a carefully selected set of pinned<br>
revisions for its releases. Did someone pin a broken release without<br>
testing?<br>
<br>
FWIW: for Plone releases I always make a full release, install that in a<br>
sandbox, run all tests in it, setup a new site and test its web<br>
interface, do an upgrade test, etc. It's tedious but can catch real<br>
errors. I would suggest using a similar process for grok releases.<br>
<br>
Wichert.<br>
<font color="#888888"><br>
<br>
--<br>
Wichert Akkerman <<a href="mailto:wichert@wiggy.net">wichert@wiggy.net</a>> It is simple to make things.<br>
<a href="http://www.wiggy.net/" target="_blank">http://www.wiggy.net/</a> It is hard to make things simple.<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Grok-dev mailing list<br>
<a href="mailto:Grok-dev@zope.org">Grok-dev@zope.org</a><br>
<a href="http://mail.zope.org/mailman/listinfo/grok-dev" target="_blank">http://mail.zope.org/mailman/listinfo/grok-dev</a><br>
</div></div></blockquote></div><br>