Hash: SHA1

Martijn Faassen wrote:
> Roger Ineichen wrote:
>> Hi Tres
>>> Whoever released those two eggs (the '.dev-r#####' ones) need 
>>> to release "real" updated packages, and then grok 0.11.1 
>>> should be released using them.
>> As far as I understand, this does not happen if you 
>> depend on a KGS, right?
>> Does the grok release not use the KGS from Stephan?
> Not yet. We intend to look at that list at some point. Of course the KGS 
> probably doesn't contain recent enough packages to support the REST 
> changes.

If the REST stuff depended on unreleased versions of upstream packages,
then it should not have been merged until those packages were released
in an acceptable (non-snapshot) form.

> The other problem with KGS is that I absolutely want to fix lists of 
> packages into Grok itself and never rely on any system that can cause 
> the list of packages that could be updated. KGS will get bugfix 
> releases. These will inevitably break something on occassion. I have no 
> idea what will happen once 3.5 packages will start to appear, either.

A KGS needs to have the following properties:

 - The "generation zero" of any KGS is an empty set of revisions.

 - By default, any revision N of a KGS starts out as a "draft" version
   which is an empty layer over version N-1.  Changes to the draft
   then shadow any versions in the prior revision.

 - Once "finalized" / "published", a given revision of a KGS can
   *never* be changed.

 - Any KGS can be derived from the published version of another KGS,
   with additions of new distributions / versions and updates of
   versions for underlying distributions.

 - In conjunction with a "find-links" site which promises never to
   remove any distribution which has been included in a published
   revision of a KGS, the current 'version.cfg' (and workalike)
   files are sufficient to establish a KGS.  Without that promise,
   however, those files can't be considered as defining a KGS.


 - Given that all distribution versions mentioned in a KGS are
   stored at a trusted / reliable URL, any immutable KGS revision
   can be trivially transformed into a PyPI package index: each
   distribution will have exactly one allowed version, which will
   point to a single URL on a reliable server.

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to