[Grok-dev] Re: AW: Re: Grok 0.11 released!

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
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.
>>>
>>> DEATH TO FAUX PACKAGES!
>> 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.

Therefore,

 - 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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHNS+v+gerLs4ltQ4RAl/rAJ9lDeB9nOXGab+/uAithNjeMeREkwCgguHF
5qA0vftURPPCW7SR2yZVTmk=
=NBMc
-----END PGP SIGNATURE-----