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 > project. > > 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. Jim -- Jim Fulton _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
