Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Some thoughts on KGS

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


jim at zope

Jul 2, 2009, 4:19 AM

Post #1 of 4 (418 views)
Permalink
Some thoughts on KGS

I think the KGS should define 3 categories of packages:

- ZTK packages

These are packages we maintain and expect people to build things on.

- Test packages

These are packages that build on the ZTK. These are used to test
the ZTK packages, but aren't part
of the ZTK.

- dependencies of ZTK packages or test packages.

Note that the ZTK should probably avoid non-third-party
dependencies that are not
part of the ZTK. There are some fuzzy cases, like ZODB and ZConfig.

I propose that any test infrastructure we come up with needs to handle
these 3 cases. In any cases, the test infrastructure needs to fix
version for all of the categories of packages and there needs to be a
formal process (uh, like tests passing :) for updating the
configuration.

Jim

--
Jim Fulton
Zope Corporation


_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Aug 6, 2009, 9:16 AM

Post #2 of 4 (265 views)
Permalink
Re: Some thoughts on KGS [In reply to]

Hey,

Jim Fulton wrote:
> I think the KGS should define 3 categories of packages:
>
> - ZTK packages
>
> These are packages we maintain and expect people to build things on.
>
> - Test packages
>
> These are packages that build on the ZTK. These are used to test
> the ZTK packages, but aren't part
> of the ZTK.

Could you give an example ofa 'test package'? I'm having trouble
thinking of what these might be.

> - dependencies of ZTK packages or test packages.

> Note that the ZTK should probably avoid non-third-party
> dependencies that are not
> part of the ZTK. There are some fuzzy cases, like ZODB and ZConfig.

What would 'dependencies of ZTK packages or test packages' be? Aren't
those third party packages?

> I propose that any test infrastructure we come up with needs to handle
> these 3 cases. In any cases, the test infrastructure needs to fix
> version for all of the categories of packages and there needs to be a
> formal process (uh, like tests passing :) for updating the
> configuration.

Could you say a bit more about what's motivating this proposal?

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


jim at zope

Aug 6, 2009, 10:28 AM

Post #3 of 4 (266 views)
Permalink
Re: Some thoughts on KGS [In reply to]

On Thu, Aug 6, 2009 at 12:16 PM, Martijn Faassen<faassen[at]startifact.com> wrote:
> Hey,
>
> Jim Fulton wrote:
>> I think the KGS should define 3 categories of packages:
>>
>> - ZTK packages
>>
>>    These are packages we maintain and expect people to build things on.
>>
>> - Test packages
>>
>>     These are packages that build on the ZTK. These are used to test
>> the ZTK packages, but aren't part
>>     of the ZTK.
>
> Could you give an example ofa  'test package'? I'm having trouble
> thinking of what these might be.

Perhaps Grok (or keas ), or some higher-level framework or application
built with the framework. The idea is to catch cases where we've
changed the APIs in a backward incompatible way.


>> - dependencies of ZTK packages or test packages.
>
>>    Note that the ZTK should probably avoid non-third-party
>> dependencies that are not
>>    part of the ZTK. There are some fuzzy cases, like ZODB and ZConfig.
>
> What would 'dependencies of ZTK packages or test packages' be?

Packages that they depend on. Was that a trick question? :)

> Aren't
> those third party packages?

Yes.

>> I propose that any test infrastructure we come up with needs to handle
>> these 3 cases.  In any cases, the test infrastructure needs to fix
>> version for all of the categories of packages and there needs to be a
>> formal process (uh, like tests passing :) for updating the
>> configuration.
>
> Could you say a bit more about what's motivating this proposal?

There's been way too much breakage lately. We have a number of
applications here at ZC that can't be upgraded without a huge amount
of effort to figure out what combination of packages actually work
together. There have also been backward incompatible changes. We'll
deal with those, but aren't going to spend time on that until there's
a solid foundation.

We need a known tested configuration of packages, with their
dependencies, that are knows to work -- or at least pass their tests.
The purpose of my proposal was to try to move this forward.

Jim

--
Jim Fulton
_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


faassen at startifact

Aug 8, 2009, 9:32 AM

Post #4 of 4 (252 views)
Permalink
Re: Some thoughts on KGS [In reply to]

Jim Fulton wrote:
> On Thu, Aug 6, 2009 at 12:16 PM, Martijn Faassen<faassen[at]startifact.com> wrote:
[snip]
>> Could you give an example ofa 'test package'? I'm having trouble
>> thinking of what these might be.
>
> Perhaps Grok (or keas ), or some higher-level framework or application
> built with the framework. The idea is to catch cases where we've
> changed the APIs in a backward incompatible way.

Ah, I understand better now. I was thinking more of dedicated test
packages, but you're talking about libraries and frameworks that use
parts of the ZTK, and that we could use to see whether we break anything.

[snip]
>>> I propose that any test infrastructure we come up with needs to handle
>>> these 3 cases. In any cases, the test infrastructure needs to fix
>>> version for all of the categories of packages and there needs to be a
>>> formal process (uh, like tests passing :) for updating the
>>> configuration.
>> Could you say a bit more about what's motivating this proposal?
>
> There's been way too much breakage lately. We have a number of
> applications here at ZC that can't be upgraded without a huge amount
> of effort to figure out what combination of packages actually work
> together. There have also been backward incompatible changes. We'll
> deal with those, but aren't going to spend time on that until there's
> a solid foundation.
>
> We need a known tested configuration of packages, with their
> dependencies, that are knows to work -- or at least pass their tests.
> The purpose of my proposal was to try to move this forward.

Understood. Putting the independent pieces back together again in a
known-good-set will indeed require work. During the sprint earlier this
year we developed z3c.recipe.compattest to help with that, and I believe
the KGS toolset also has tools to do this (the difference being
compattest runs tests of each package in isolation whereas KGS runs them
when all are imported).

Basically the primary thing we need right now is a sensible KGS that we
can use as a foundation to upgrade towards, instead of a moving target.

Regards,

Martijn

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.