[Grok-dev] Grok and chameleon

Martijn Faassen faassen at startifact.com
Mon Feb 8 12:50:00 EST 2010

Hi there,

Martin Aspeli wrote:
> Think of it this way instead: We've published a package that promises a 
> certain way of working right now. If we're making major policy changes, 
> we need to consider backwards compatibility for consumers of that 
> package. That's not "too many stakeholders". That's everyone who decided 
> to use a package that promised to be useful to people not using 
> Grok-the-framework in its entirety.

I'm saying that Grok the framework should be the main driver of where 
these packages go. That's how it has been anyway, and nobody was 

If that means that grokcore.view totally changes the way its policy 
works *because that's good for Grok*, then so be it. It'll be a big 
feature release. We'll think about it carefully.

If there are other stakeholders that use these packages (and there are), 
they either help us in a way that's also good for them, or they adapt to 
the new version at some point. I really don't want the grokcore.* 
packages to turn into another ZTK where nobody can make policy.

>> So, Zope 2's stakeholders will just need to figure out how to make our
>> changes work with Zope 2, and the more you help us transition to
>> Chameleon the more control you'll have over how it's done. :)
> If that's your way of saying that you don't care about other users of 
> grokcore.*, and you're not going to worry about backwards compatibility, 
> then I've misunderstood the purpose of grokcore.* in the first place. I 
> hope that's not what you're saying, though. :)
> If it is, I have a lot of code to rewrite. :(

Heh, if you so little trust you have to worry about that, then you can 
just as well go away. If you do trust us, please do the silliness on 
another mailing list.

I realize I started this silliness, so I'll stop now. So that's the last 
I'll try to say in this policy debate. I'm sure we'll all be fine in the 
end anyway.



More information about the Grok-dev mailing list