Hey,
Given the momentary confusion surrounding the release of a broken
package. By broken package in this case I mean something which seriously
breaks many many Zope 3 installations in an obvious way.
I think it might be wise to start working out some procedure surrounding
such a situation.
* if a package is broken, the preferred route is to upload a new, fixed
package with a later version number as soon as possible. (incidentally,
it appears wise to verify manually that the new egg is indeed there by
checking the download server.)
* sometimes that may not be immediately possible. There are some routes
to solving this in this case. They all involve a message to the mailing
list - this is something that went very right here (I had the problem,
and could immediately see others had it too). Then:
* everybody adjusts their buildout.cfg according to instructions
or
* remove the dud from your egg cache, and run buildout with -N
(according to instrucitons)
or
* the broken package is removed from the server along with
instructions for people who already got it to remove it from their egg
cache.
The first procedure makes people change their buildout and runs the risk
they forget to change it back. It assumes lots of people adjust lots of
buildout.cfgs
The last procedure seems optimal to me - more people are stopped from
being infected with the broken package, and people who did get the
broken package have simple way to fix it (remove it, re-run buildout).
I'd therefore suggest that *if* we can't release a fixed egg for
logistical reasons within a brief time-period, we proceed to remove the
broken egg from the server and post a message to the mailing list saying
it's broken.
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
