[Zope-dev] KGS trunk without failures

Martijn Faassen faassen at startifact.com
Sat Aug 8 13:22:59 EDT 2009


Hey,

Wolfgang Schnerring wrote:
> * Fabio Tranchitella <kobold at kobold.it> [2009-08-07 11:46]:
>> * 2009-08-07 11:42, Wolfgang Schnerring wrote:
>>   http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg
>> IMHO the KGS testing should be done using the controlled-packages.cfg and
>> not versions, because some of the packages in the KGS are marked as not to
>> be tested.
> 
> If controlled-packages.cfg is to be the authoritative represenation of
> the KGS (and maybe it should be, since it contains more information than
> versions.cfg) then I'd probably wish for a buildout recipe that can pin
> versions based on that data format, because I much prefer less moving
> parts.
> 
> In other words, I would very much like a single gesture to tell buildout
> "use this KGS": extends=something-or-other.cfg. The rest should Just Work(tm).

I'm +1 on this, the less moving parts the better and the less 
compiling/generation we can get away with, the better too. It needs to 
be as straightforward as we can make it.

I do think we need a computer readable system that includes information 
like this:

* whether a project is in a KGS (such as for the ZTK)

* whether a project is used to test a KGS (a package not in the ZTK but 
used to test whether changes don't induce breakage, let's say, 
grokcore.component)

* the locked down version of the package.

* where the *next* version of the locked down version is being 
developed. Generally this is the SVN trunk, but could be a stable branch.

The system that manages this shouldn't be tied to Zope in particular. 
It'd be great for managing, say, Grok's, KGS too.

Regards,

Martijn



More information about the Zope-Dev mailing list