[Zope-dev] KGS Site Updated

[Stephan Richter]

On Sunday 18 November 2007, Chris McDonough wrote:
> > I disagree. This is not what this means to me. I think a KGS can
> > receive bug
> > fix releases, which the Zope 3.4 KGS does. However, no new feature
> > releases
> > are allowed.
>
> In the Linux world, these purposes are served by separate indexes
> (e.g. Debian security releases are in their own index).  There's no
> problem with what you're saying, it's just not a source for repeatable
> installations, which is something that's required for many builds.

Yes, I agree. I accommodated those needs by having versioned links.html, 
versions.cfg, controlled-packages.cfg, and now minimal/ files and 
directories. Those will *never* change once released. (Of course there will 
be versions like "3.4.1dev" that change until "3.4.1" is released, simply so 
that I do not have to version every single little change to the KGS while 
testing. But maybe that is even desirable at some point. We will see.)

> Even if there are bugfixes available, you may not want them, or you
> may have fixed the bugs your own way already (though patches or what-
> have you).  Maybe the KGS isn't it, but there needs to be a way to get
> the very same packages, unfailingly, every time, no exceptions for
> bugfixes, etc.  I wish the KGS was this but it still isn't it.

Well, the versioned versions.cfg file will not change. In the buildout world, 
I think most people will end up using versions-*.cfg when pinning down 
versions plus specify their own version block in their buildout.cfg for 
packages that we do not control.

> >> The first is true for what we have now neither of the "minimal" set
> >> or
> >> the set you're calling the "KGS".
> >
> > Right. Note that versions-*.cfg and links-*cfg are frozen. I am
> > probably going
> > to freeze minimal/ as have minimal-*/ too.
>
> Will they will change for bugfixes?

Nope. That's the reason they are frozen. They are like tags in SVN.

> I have tried buildout, of course.  Massaging the index to meet some
> set of expectations developers have of the client they use to install
> the software is fine, you did a lot of work to do this, which is
> appreciated, and it's your index.   But I suggest that we don't
> discount the *really KGS* requirement, which is *absolutely repeatable
> builds* (today, tomorrow, two years from now), and we let people know
> that the KGS is not that.

Why? I have listened to the community very early on, reacting to the need 
having certain frozen output. A few weeks back I sent a mail to the zope-dev 
_[1] list outlining how I think the index can be used in buildout. Since 
then, functionality has only expanded and other combinations are possible 
now.

.. [1] http://mail.zope.org/pipermail/zope-dev/2007-November/030210.html

So if you go to http://download.zope.org/zope3.4/intro.html into the 
sub-section "Version 3.4.0b2" you see a bunch of links. With the exception of 
the "Index" link, all other links point to versioned file and directories, 
which will not change. Also, any of the versioned files and directories do 
not contain references to packages that are not controlled by the KGS.

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