ct at gocept
Jul 7, 2009, 2:03 PM
Post #27 of 28
(510 views)
Permalink
|
Hi,
On 07/01/2009 11:12 AM, Jim Fulton wrote:
>
>> [...]
>>
>> You can specify include and exclude options; the default is to
>> include a
>> list of zope.* packages that we pulled out of thin air at the sprint,
>> it'd probably be better to use the KGS as a default instead -- but
>> that
>> would duplicate even more zope.release functionality.
>
> Where is this list? In the recipe?
The recipe takes two arguments:
- a list of regular expressions to describe packages that should be
included
- a list of regular expressions to describe packages that should be
excluded
There is currently a builtin list for each of them that gets appended to
the ones you specify when using the recipe in your buildout.
>> I think it would be useful to standardize on *one* compatibility
>> testing
>> method for the ZTK (and then document it).
>
> Yes.
>
>> My instinct would be to separate KGS handling from tarball creation
>> from
>> testing, that is, remove the test-business from zope.release and use
>> the
>> compattest recipe instead. (Alternatively, retire compattest and have
>> zope.release gain the ability to use trunks so it could be used for
>> continuous integration purposes as well -- but that doesn't feel quite
>> right, to be honest)
>>
>> Thoughts?
>
>
> I agree we need one way to do this. I think the KGS concept is right.
> I think there should be a known good configuration of packages and a
> way to evolve it. The configuration should be changed only after
> testing changes. The configuration needs to include Python versions
> that it is tested with. Beyond that, I don't care what the process is
> as long as it is documented.
The compattest is intended to check the trunks of packages located in
one repository like svn.zope.org against the development version of the
package you're working on so you can see whether your changes will cause
others that depend on you to break.
I think it's one of the issues we need to solve in our process and it
was actually very valuable when doing the large dependency refactoring
at the sprint.
If you have a multi-core machine, you can also ask it to run the various
test runners in parallel. I was able to execute the 100+ package tests
in less than 10 minutes on an 8-core machine.
Christian
--
Christian Theune · ct [at] gocept
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
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )
|
