On Sun, Jan 3, 2010 at 3:51 PM, Martijn Faassen <faas...@startifact.com> wrote:
> Hi there,
> So here's my proposed solution for the ZTK shrinking issue:
> The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since
> Zope 2 forked the ZTK in response and continued to make changes to their
> fork, I've tried to keep it in sync with the Zope 2 fork.
> I've created a new 'zopeapp' package that expands the ZTK with zope.app.
> packages in my sandbox. This extracts that information from the ZTK.
> Hopefully after we get some feedback from other steering group members
> (very silent indeed in the holiday period when all this happened) we can
> make these two projects the official one: a ZTK project and a zopeapp
> A few things I ask the ZTK maintainers:
> I ask the ZTK maintainers to have the same concern for the zope.app
> packages as for any other user of the ZTK: work to support zopeapp's
> compatibility with the ZTK. If the zopeapp maintainers have issues,
> listen to them seriously. I think everybody can agree that this is
> within the ZTK mandate for the time being, as zopeapp clearly exists and
> is being used by a significant amount of people. (I'd like to work to
> retire it by making it used by far less people)
> I also strongly encourage the ZTK maintainers to consider the situation
> of backwards compatibility seriously. Help people transition from their
> code now to the ZTK. Helping everybody migrate to the ZTK smoothly
> increases the value of the ZTK itself. Obviously I cannot *force* ZTK
> maintainers to worry about this. Instead I'm appealing to your
> self-interest. And of course the transition burden is shared and should
> not fall solely or even predominantly on the ZTK maintainers.
> I also think we as ZTK maintainers should better consider the concerns
> of other users of the ZTK. In this case, Zope 2 had less of a concern
> for zope.app than Grok or Zope 3. I didn't even understand this until
> the debate was further along. The concerns of others should be
> considered as well instead of simply rejected. We usually can find ways
> to balance the concerns of everybody. To that end concerns (or lack
> thereof) should be clearly communicated and be listened to.
Big +1 from me.
I'd especially like to encourage emphasis on backward compatibility.
This is key for us.
Some specific advice:
- When we refactor zope.app.foo to be zope.foo (or something else),
rather than changing
zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible.
- When we "clean up" and existing package without creating a new one
in a way that
is backward incompatible, let's update the major version number.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -