Uses of the ZTK and how it relates to management
On Wed, Mar 3, 2010 at 3:14 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-03 20:41, Chris McDonough wrote:
Why wouldn't that be worked out here? Is it because you just want the mechanics of such a project done elsewhere without having to see it talked about on this maillist? Or is it because you disagree that it should be done? Or... what?
The main issue is related to the different use cases we have for the ZTK: some people use (or want to use) the ZTK as a monolithic set of packages that can be considered "somehow" the upgrade path from zope3 with the exclusion of zope.app.* (if possible).
Others (like me and you, Chris) see the ZTK as a set of core packages (mainly the bicycle repair kit, which is not the only self-contained subset of useful packages though) plus a huge load of dependencies we are bringing forward from the "old" zope3 releases.
Others, like me and Martijn and probably many many others, see the ZTK as a set of packages that can be used in various subsets and combination. We want as few dependencies as possible. We also want a configuration of versions that are known to work together because they are tested together. We want stability and we want processes that will help us move forward. I don't think the people who want to advance Blue Bream are really all that different.
Our points of view are totally different,
I don't think so. Where we seem to differ is on the specific point of change management, and especially testing.
and I suppose the first group of people fear that fragmentation can influence the quality and stability of the ZTK as a whole.
The ZTK was created in part to deal with instability issues arising from people working on parts without testing the whole.
In my opinion, we can only gain defining explicitly the bicycle repair kit if somebody is willing to maintain it (and I refer to documentation and marketing stuff, not code because it is already very stable). If this cannot be done with consensus on zope-dev, but a group of people is really interested in it, I don't think it can be or should be stopped and, TBH, I don't see how it can influence the ZTK.
I don't think anyone is objecting to marketing efforts. Even these core components will need maintenance and updates from time to time. *An* important question is how these changes will be ma naged in the context of the larger community. Jim -- Jim Fulton
On 03/03/2010 09:43 PM, Jim Fulton wrote:
On Wed, Mar 3, 2010 at 3:14 PM, Fabio Tranchitella <kobold@kobold.it> wrote:
* 2010-03-03 20:41, Chris McDonough wrote:
Why wouldn't that be worked out here? Is it because you just want the mechanics of such a project done elsewhere without having to see it talked about on this maillist? Or is it because you disagree that it should be done? Or... what?
The main issue is related to the different use cases we have for the ZTK: some people use (or want to use) the ZTK as a monolithic set of packages that can be considered "somehow" the upgrade path from zope3 with the exclusion of zope.app.* (if possible).
Others (like me and you, Chris) see the ZTK as a set of core packages (mainly the bicycle repair kit, which is not the only self-contained subset of useful packages though) plus a huge load of dependencies we are bringing forward from the "old" zope3 releases.
Others, like me and Martijn and probably many many others, see the ZTK as a set of packages that can be used in various subsets and combination. We want as few dependencies as possible. We also want a configuration of versions that are known to work together because they are tested together. We want stability and we want processes that will help us move forward.
A thought that came up when reading this paragraph: another option restructuring/grouping to reduce the amount of packages may be to join smaller packages with weird boundaries into larger ones again. (Not that I suggest this to be an ultimate option, nor do I know from the top of my head any candidates for this, but we can keep that on the list of options we have.) Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <ct@gocept.com> wrote:
A thought that came up when reading this paragraph: another option restructuring/grouping to reduce the amount of packages may be to join smaller packages with weird boundaries into larger ones again. (Not that I suggest this to be an ultimate option, nor do I know from the top of my head any candidates for this, but we can keep that on the list of options we have.)
I think this is a good idea, but I wouldn't want to do it on a package level. Rather do it on the distribution level. Once the distutils2 improvements are available, we have the means to say "distribution A obsoletes B". As a simple example that would allow us to put zope.event into the zope.component distribution, without having to change any import paths or setup.py install_requires lines. The zope.component distribution would have the metadata to say "I obsolete zope.event", so if someone has such a version of zope.component, requirements of the zope.event distribution would be automatically satisfied. This same method could be taken to build more functional distribution out of related packages we have today. These distributions might also be easier to market, document and explain. But they come with the downside of more buy-in per distribution. Figuring out how packages are actually used and which ones are used independently is no small task. Hanno
On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <ct@gocept.com> wrote:
A thought that came up when reading this paragraph: another option restructuring/grouping to reduce the amount of packages may be to join smaller packages with weird boundaries into larger ones again. (Not that I suggest this to be an ultimate option, nor do I know from the top of my head any candidates for this, but we can keep that on the list of options we have.)
I think this is a good idea, but I wouldn't want to do it on a package level. Rather do it on the distribution level. Once the distutils2 improvements are available, we have the means to say "distribution A obsoletes B".
As a simple example that would allow us to put zope.event into the zope.component distribution, without having to change any import paths or setup.py install_requires lines. The zope.component distribution would have the metadata to say "I obsolete zope.event", so if someone has such a version of zope.component, requirements of the zope.event distribution would be automatically satisfied.
This same method could be taken to build more functional distribution out of related packages we have today. These distributions might also be easier to market, document and explain. But they come with the downside of more buy-in per distribution. Figuring out how packages are actually used and which ones are used independently is no small task.
Your description of the mechanism sounds interesting. In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component. Ideally, I'd like other projects to adopt zope.event, or for something like zope.event to be included in the standard library, although, I'm unlikely to push that politically, so it will probably never happen. :/ Jim -- Jim Fulton
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
On Thu, Mar 4, 2010 at 5:35 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <ct@gocept.com> wrote:
A thought that came up when reading this paragraph: another option restructuring/grouping to reduce the amount of packages may be to join smaller packages with weird boundaries into larger ones again. (Not that I suggest this to be an ultimate option, nor do I know from the top of my head any candidates for this, but we can keep that on the list of options we have.)
I think this is a good idea, but I wouldn't want to do it on a package level. Rather do it on the distribution level. Once the distutils2 improvements are available, we have the means to say "distribution A obsoletes B".
As a simple example that would allow us to put zope.event into the zope.component distribution, without having to change any import paths or setup.py install_requires lines. The zope.component distribution would have the metadata to say "I obsolete zope.event", so if someone has such a version of zope.component, requirements of the zope.event distribution would be automatically satisfied.
This same method could be taken to build more functional distribution out of related packages we have today. These distributions might also be easier to market, document and explain. But they come with the downside of more buy-in per distribution. Figuring out how packages are actually used and which ones are used independently is no small task.
Your description of the mechanism sounds interesting.
In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component.
I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional. zope.event will still be used if it is around but zope.component will provide it's own implementation if not. Other packages which only depend on zope.component can break their dependency on zope.event.
Ideally, I'd like other projects to adopt zope.event, or for something like zope.event to be included in the standard library, although, I'm unlikely to push that politically, so it will probably never happen. :/
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 )
-- Brian Sutherland
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component.
I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional.
Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort. -- Benji York
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote:
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component.
I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional.
Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort.
One point is backwards compatibility, the other is to allow zope.component subscribers to listen to ZODB events if the ZODB only depends on zope.event but not on zope.component. -- Brian Sutherland
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote:
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component.
I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional.
Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort.
Actually, I misunderstood your question. Personally, I also don't think it's worth the effort. But it's come up a few times already, so is obviously something some group of people want. The effort, also, is actually quite small as can be seen on the branch. Perhaps it's even an effort saver if it prevents the topic coming up again and again ;) -- Brian Sutherland
On Thu, Mar 4, 2010 at 11:34 AM, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote:
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland <brian@vanguardistas.net> wrote:
On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote:
In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component.
I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional.
Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort.
Actually, I misunderstood your question.
Good, because while reading you're response I was so confused I worried that I had recently had a stroke and not realized it yet. -- Benji York
On 03/04/2010 11:35 AM, Hanno Schlichting wrote:
On Thu, Mar 4, 2010 at 7:19 AM, Christian Theune <ct@gocept.com> wrote:
A thought that came up when reading this paragraph: another option restructuring/grouping to reduce the amount of packages may be to join smaller packages with weird boundaries into larger ones again. (Not that I suggest this to be an ultimate option, nor do I know from the top of my head any candidates for this, but we can keep that on the list of options we have.)
I think this is a good idea, but I wouldn't want to do it on a package level. Rather do it on the distribution level. Once the distutils2 improvements are available, we have the means to say "distribution A obsoletes B".
Interesting. On the first impression that sounds like a good abstraction and tool. I guess not everyone aware that distribution != package is possible and maybe even useful. ;) Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hello, Wednesday, March 3, 2010, 9:43:44 PM, you wrote: JF> Others, like me and Martijn and probably many many others, see the ZTK JF> as a set of packages that can be used in various subsets and JF> combination. We want as few dependencies as possible. We also want a JF> configuration of versions that are known to work together because they JF> are tested together. We want stability and we want processes that JF> will help us move forward. I don't think the people who want to JF> advance Blue Bream are really all that different. Well said. A big +sys.maxint. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: In the end it will not matter to us whether we fought with flails or reeds. It will matter to us greatly on what side we fought. - G.K. Chesterton
participants (6)
-
Adam GROSZER -
Benji York -
Brian Sutherland -
Christian Theune -
Hanno Schlichting -
Jim Fulton