[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