On Friday 05 October 2007 14:49, Jim Fulton wrote:
> I discussed this a bit this afternoon with Stephan and we came up
> with an idea that we think might help. Stephan is going to try to
> prototype it. I'll try to explain it
the first version of the tools required to develop KGS's is now done. I simply
added them to the ``zc.mirrorcheeseshopslashsimple``. That said, here is what
1. There is a new index located at http://download.zope.org/zope3.4.
2. This index contains all PyPI packages.
3. There is a file called "controlled-packages.cfg" that has a list of
projects for which we define a set of versions that are known stable within
this index. The projects' pages are rewritten to only link to the stable
4. There is also a "buildout.cfg" that is generated from the controlled
packages config file. You can download it and use it to test the complete set
of packages. (There are currently test failures!)
The good part about it is that the index works right now giving application
developers some stability. However, there are still some issues:
1. Not all zope.* and zope.app* packages are yet listed. An example
2. How many packages should be controlled in this index? I think we should
definitely add packages from z3c and the zc namespace.
3. The workflow of maintaining the KGS is somewhat unclear. Here is a workflow
that works right now:
(a) Install zc.mirrorcheeseshopslashsimple tools.
(b) Download "controlled-packages.cfg" from the set you want to modify or
(c) Use the "generate-buildout" script to create a "buildout.cfg" file.
(d) Without using the KGS index (so you can pickup new versions), run
buildout, so that the "test" script is created.
(e-I) Change "controlled-packages.cfg" to include a new version of a package
and go back to (c).
(e-II) Alternatively, if you want to create a new release of a package to fix
issues in the KGS, you can list the package in "buildout.cfg" as a develop
egg and make a new version entry in "controlled-packages.cfg" when you have
released a new version.
(f) Once you are done, upload "controlled-packages.cfg" again. Note that this
file is not under version control, so be careful to not overwrite someones
work. This is probably a good reason to only have one release manager per
Overall I am very pleased with that approach since it addresses our current
instability problems. It also resembles QA methods used by the Linux
BTW, I shamelessly copied the initial list of stable versions from grok.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list