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
changed).
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
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
