Hey, Wolfgang Schnerring wrote:
* Fabio Tranchitella <kobold@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-packag... 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