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


* remove the dud from your egg cache, and run buildout with -N (according to instrucitons)


* 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.



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to