I agree with everything except:
On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote:
Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS.
I don't agree with this statement. What we want is that the Zope 3 KGS
becomes based on the ZTK KGS. After that happens,
Lennart Regebro wrote:
I agree with everything except:
On Tue, Dec 29, 2009 at 23:30, Martijn Faassen faas...@startifact.com wrote:
Goal 2: We want users to use the ZTK instead of the Zope 3.4 KGS.
I don't agree with this statement. What we want is that the Zope 3 KGS
becomes based on the
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect here. As I see it the ZTK is not a 'leaner,
On 12/29/09 16:39 , Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner dependencies.
I feel a disconnect here. As I see it
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote:
It seems that you want to have a 'ZTK+' which aims to be backwards
compatible with Zope 3 but is somehow not Zope 3 itself. That is
something that not everybody appears to be interested in judging by the
lack of
On 12/29/09 17:00 , Martijn Faassen wrote:
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope packages.
For these folks, any reduction in number of dependencies and test maintenance
is a net
Wichert Akkerman wrote:
[snip]
You are ignoring my point though: why should the ZTK have to be burdened
with trying to be backwards compatible with something that it never was?
Why are you insisting on putting Zope3 in it?
We should not remove it until we have a good way to upgrade people
Chris McDonough wrote:
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope packages.
For these folks, any reduction in number of dependencies and
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it responsibly. Not just disclaim
responsibility and drop it all.
So far I defined the ZTK based on what we
Fred Drake wrote:
On Tue, Dec 29, 2009 at 10:39 AM, Wichert Akkerman wich...@wiggy.net wrote:
It seems that you want to have a 'ZTK+' which aims to be backwards
compatible with Zope 3 but is somehow not Zope 3 itself. That is
something that not everybody appears to be interested in judging by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
On 12/29/09 16:25 , Martijn Faassen wrote:
Earlier this year we decided to refocus our efforts on the ZTK, a
leaner, meaner Zope 3 with a different focus, which has code that we
really use, no UI, and with cleaner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Wichert Akkerman wrote:
[snip]
You are ignoring my point though: why should the ZTK have to be burdened
with trying to be backwards compatible with something that it never was?
Why are you insisting on putting Zope3 in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Chris McDonough wrote:
I don't think the ZTK as defined by the historical constraints under
discussion here has much attraction for a large number of folks who are
otherwise willing to put effort into maintaining Zope
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
continue to test the zope.app.* packages when we make ZTK changes, for
the
Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com
wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it responsibly. Not just disclaim
responsibility and drop it all.
So far I
Hi there,
Tres Seaver wrote:
[snip]
Who is upgrading? There are not historical users of the ZTK, only users
of package sets with greater or lesser intersections with the ZTK.
[snip]
You are acting like we have code in the wild which needs to upgrade from
some released version of the ZTK to
Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com
wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
continue to test the zope.app.* packages when we make
On Tue, Dec 29, 2009 at 23:11, Martijn Faassen faas...@startifact.com wrote:
I'm looking at this from the perspective of the discontinuity we will
introduce for existing users of the libraries that are now in the Zope
Toolkit but were formerly presented as Zope 3, and the guidance we offer
for
Hey,
Tres Seaver wrote:
[snip]
You need to identify whose ox is being gored here by dropping those
packages: I don't see anybody but you arguing for their inclusion. In
particular, I don't see anybody who knows *which* zope.app packages they
need, and has a credible argument for why those
Lennart Regebro wrote:
[snip]
What difference would there be between a zopeapp KGS and a Zope3 KGS?
Not much. More sharing between Grok, Zope 3 and Zope 2? Explicitly aimed
at supporting backwards compatibility and upgrade path only?
We've been maintaining something close to a zopeapp KGS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
On Tue, Dec 29, 2009 at 9:54 PM, Martijn Faassen faas...@startifact.com
wrote:
And let's please not turn this around: I'm not putting anything *in*.
Something was *removed*. Let's remove it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fred Drake wrote:
On Tue, Dec 29, 2009 at 4:04 PM, Martijn Faassen faas...@startifact.com
wrote:
But right now we need to provide some guidance for how people can move
away from these packages in a sane manner. And we should make sure we
Tres Seaver wrote:
Martijn Faassen wrote:
[snip]
The ZTK cannot be an excuse to just drop support for a large part of the
existing users of the ZTK. It's a *means* to do so.
What existing users does the ZTK have?
I'll rewrite that:
The ZTK cannot be an excuse to just drop support for a
On Tue, Dec 29, 2009 at 6:11 PM, Martijn Faassen faas...@startifact.com wrote:
* the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at
all.
I'm strongly in this camp. The other camps can readily be supported
on top of this view of the ZTK by providing new names for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
We have three perspectives:
* the ZTK is new, therefore the ZTK doesn't need to care about Zope 3 at
all.
+1
* the ZTK is a renamed, refocused Zope 3, therefore the ZTK needs to
care about Zope 3.
- -1
* both: the
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen
faas...@startifact.com wrote:
I think a zopeapp KGS that will help them transition existing code from
Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2
users.
Not really. Zope 2.12 is exactly that transitionary release
Hanno Schlichting wrote:
On Wed, Dec 30, 2009 at 12:11 AM, Martijn Faassen
faas...@startifact.com wrote:
I think a zopeapp KGS that will help them transition existing code from
Zope 2.12 to Zope 2.13 in working condition would be helpful to Zope 2
users.
Not really. Zope 2.12 is exactly
On Wed, Dec 30, 2009 at 12:55 AM, Martijn Faassen
faas...@startifact.com wrote:
Hanno Schlichting wrote:
Not really. Zope 2.12 is exactly that transitionary release defining a
KGS for everything that was included in Zope 2.11 (~3.4.1).
Ah, I didn't realize Zope 2.12 was already based on an
Hanno Schlichting wrote:
[snip explanation of current Zope 2 and Plone plans, thanks]
So the two main upgrade paths we have are Zope 3.3.2 to ZTK 0.5. And
then at some point in maybe 12 to 18 months a ZTK 0.5 to ZTK x.y
upgrade. This also means that an actual ZTK release, that is done
anywhere
On Wed, Dec 30, 2009 at 1:46 AM, Martijn Faassen faas...@startifact.com wrote:
Assuming ZTK x.y won't have zope.app packages, this means that those
upgrading to Zope 2.13 might be helped by a list of working versions of
those zope.app.* packages (such as the one in zopeapp), or am I wrong?
Of
32 matches
Mail list logo
