[Zope3-Users] Re: [Zope3-dev] Known-good-sets problem

[Stephan Richter]

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

Hi everyone,

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 
we have:

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 
versions.
 
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 
is "zope.viewlet".

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 
test.

(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 
KGS.

Overall I am very pleased with that approach since it addresses our current 
instability problems. It also resembles QA methods used by the Linux 
distribution creators.

BTW, I shamelessly copied the initial list of stable versions from grok.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training