On Nov 19, 2007, at 1:26 PM, Dieter Maurer wrote:

Chris McDonough wrote at 2007-11-18 16:50 -0500:
Note that if the KGS really wants to be a KGS (literally "known good",
it's a matter of semantics, not of technology):

- An invariant must be met that only one version of each package
should be present in the index.

- The set is frozen (no packages will be added to or removed from or

I do not think this is correct:

The assumption that something is "known good" can prove to be an error.

 As soon as this happens, the index is no longer "known good".

 As a consequence, it can (and should) be changed.

I agree this is a really super-useful kind of index and maybe even deserves the term "KGS".

If it makes more sense than trying to redefine "KGS", I'm arguing that there's an additional use case of a completely frozen index to get a completely repeatable set of packages, every time, "forever". For example:

- You create an automated developer "sandbox" build using the non- minimal KGS to "get zope".
  You want this build to work repeatably, every time, without fail.

- While developing, you find a bug in it that isn't yet fixed upstream.

- You modify your automated build process to patch the installed KGS files using diffs to fix the bug
  locally.  The diffs change files installed from the KGS.

Those patches may begin to fail for new runs of the automated build if someone uploads a bugfix release to a package you were patching.

This really isn't a problem, because Stephan has provided the capability and has signaled the intent to maintain frozen "minimal" sets for each "release". Now we just need to define what a "release" is ;-)

- C

Zope3-users mailing list

Reply via email to