On Nov 10, 2007 5:12 AM, Tres Seaver [EMAIL PROTECTED] wrote:
If the REST stuff depended on unreleased versions of upstream packages,
then it should not have been merged until those packages were released
in an acceptable (non-snapshot) form.
That's a good sentiment and I agre with it in
Tres Seaver wrote:
A KGS needs to have the following properties:
- The generation zero of any KGS is an empty set of revisions.
- By default, any revision N of a KGS starts out as a draft version
which is an empty layer over version N-1. Changes to the draft
then shadow any versions
On Nov 10, 2007 10:02 AM, Philipp von Weitershausen
[EMAIL PROTECTED] wrote:
I sympathize with this thinking, but as far as I understood Jim and
Stephan last night, there seems to be the goal to make a KGS for a whole
stable release branch, e.g. Zope3.4, and keep on adding bugfix
releases.
Tres Seaver wrote:
MailTemplates subclass ZopePageTemplate and expect to be text/plain by
default...
That code is there only when reading from the default content, right?
Yep.
And that file is *definitely* 'text/html'.
Well, not in the subclass no...
Why don't you just override it at
On Friday 09 November 2007, Martijn Faassen wrote:
Roger Ineichen wrote:
Hi Tres
Whoever released those two eggs (the '.dev-r#' ones) need
to release real updated packages, and then grok 0.11.1
should be released using them.
DEATH TO FAUX PACKAGES!
As far as I understand,
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000
zc-bbwin6.
Buildbot URL: http://buildbot.zope.org/
Build Reason: changes
Build Source Stamp: 3367
Blamelist:
On Nov 10, 2007 12:52 PM, Stephan Richter [EMAIL PROTECTED] wrote:
While I personally do not think that this is a good idea, I am open to the
suggestion to fix the KGS versions for a particular Zope 3.4 release. For
example, instead of having just a versions.cfg, we can expand the scripts to
On Saturday 10 November 2007, Lennart Regebro wrote:
On Nov 10, 2007 12:52 PM, Stephan Richter [EMAIL PROTECTED]
wrote:
While I personally do not think that this is a good idea, I am open to
the suggestion to fix the KGS versions for a particular Zope 3.4 release.
For example, instead of
On Nov 10, 2007 1:06 PM, Stephan Richter [EMAIL PROTECTED] wrote:
Right, I am already correctly branching the zope.release package. It contains
the controlled-packages.cfg. Using the scripts in zope.release, it is trivial
to render versions.cfg; I mean as in: ./bin/generate-versions
I have
Summary of messages to the zope-tests list.
Period Fri Nov 9 13:00:00 2007 UTC to Sat Nov 10 13:00:00 2007 UTC.
There were 5 messages: 5 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2.7 Python-2.3.6 : Linux
From: Zope Unit Tests
Date: Fri Nov 9 20:53:35 EST 2007
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Tres Seaver wrote:
A KGS needs to have the following properties:
- The generation zero of any KGS is an empty set of revisions.
- By default, any revision N of a KGS starts out as a draft version
which is
On Friday 09 November 2007, Tres Seaver wrote:
A KGS needs to have the following properties:
- The generation zero of any KGS is an empty set of revisions.
Yes, luckily we are far beyond that point.
- By default, any revision N of a KGS starts out as a draft version
which is an empty
On 10 Nov 2007, at 14:06 , Tres Seaver wrote:
If we have software which can generate the pacakge index at a URL
for a
KGS, then it could certainly generate a 'version.cfg' as well, to
support buildout.
We already do. Stephan's zope.release does that already. The file is
actually available
On Friday 09 November 2007, Lennart Regebro wrote:
On Nov 9, 2007 4:06 PM, Roger Ineichen [EMAIL PROTECTED] wrote:
Create our own locked down index?
I think so because,
Surely there must be a way to say I want to use THAT KGS over there.
Except for this module, that should hav this
On Friday 09 November 2007, Martin Aspeli wrote:
Surely there must be a way to say I want to use THAT KGS over there.
Except for this module, that should hav this version. And of course,
all these bunch of eggs which isn't dfined in that KGS at all.
Unfortunately, this is not how the
On Saturday 10 November 2007, Stephan Richter wrote:
Could we create a grok KGS which is generated by a python-script, that
takes the correct zope3 KGS as a base?
Based on my son's behavior today, you will be able to do this in a few
hours.
Okay, this is now done. It is all documented
Hi there,
I've been doing some more thinking about external version indexes (like
Grok's versions.cfg on a URL, and like KGS) and why they won't solve all
our problems. I have a new way to express it, so let me try it out on
you all.
What KGS solves is that it allows the ongoing development
17 matches
Mail list logo
