RE: [ZODB-Dev] RE: RE: RE: PersistentMapping

2005-11-22 Thread Tim Peters
[Thomas Lotze]
> Tests... there are test suites for PersistentMapping both in
> src/ZODB/tests/testPersistentMapping.py (which is the one that checkin
> message talked about) and one in src/persistent/tests/test_mapping.py
> (which I added when I found test_list.py, but no mapping tests in that
> place). Now there are two test suites for persistent mapping, just as
> there are for lists. In the case of lists it's even clearer than for
> mappings that the duplication is unnecessary as the test code is more or
> less the same. The tests in src/ZODB/tests were touched more recently
> than those in src/persistent/tests according to svn, but IMO it's more
> obvious to test lists and mappings close to where they are defined. What
> to do about this?

The best idea is to clean it up so that it makes good sense.  There's lots
of historical cruft in the ZODB code base that doesn't make much sense
anymore.

>> Looks like the 3.5 branch got overlooked.  Merging rev 38076 from 3.4
>> branch to 3.5 branch would be fine.

> This yields a large conflict in 3.5's NEWS.txt. Should I just leave it
> untouched and not modify old news?

"Old" news will become "new" news again, when the next micro release in the
ZODB 3.5 line is made.  3.5.1 is current.  All changes made now on the 3.5
branch will eventually show up in a 3.5.2 release, and NEWS.txt on the 3.5
branch should be changed to record those changes as they're made (the idea
that a "release manager" is going to dig thru ZODB history to do this at the
last second before a release is a fantasy -- won't happen).

BTW, merges to NEWS-like files generally don't work well across branches.
What to do instead:

- Do the merge.

- Do "svn revert NEWS.txt" to throw away the botched merged on that
  single file.

- Edit NEWS.txt by hand, inserting branch-appropriate NEWS for what
  changed in the rest of the merge.  Usually this amounts to just
  copying paragraphs from one NEWS.txt to another, changing version
  numbers in an obvious way.

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


RE: [ZODB-Dev] RE: RE: RE: PersistentMapping

2005-11-20 Thread Tim Peters
[Christian Theune]
> The whole testing story together with all the active branches and
> platforms sounds like we want to have some buildbot clients for ZODB as
> well. I could set up a buildbot client on Windows 2k and Linux to test
> various ZODB branches ...
>
> That could be added to the Zope buildbot then ... Any oppinions?

I think that's an excellent idea -- especially since the Zopes were fiddled
recently to run far fewer tests.  That means, in particular, that there's no
longer any regular testing of ZODB (ZODB's test suite used to get run as
part of running the Zope 2 and Zope 3 tests, but not anymore).

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


RE: [ZODB-Dev] RE: RE: RE: PersistentMapping

2005-11-20 Thread Christian Theune
Am Freitag, den 18.11.2005, 11:25 -0500 schrieb Tim Peters:
> It's more likely due to people fiddling with zpkg.  "setup.py build" _had_
> worked fine for running the tests for years, and I know it still worked fine
> a few months ago.  But I don't normally do that, so didn't notice when it
> broke.  It's not due to changes in ZODB code (no relevant changes have been
> made there -- or at least none that I made ;-)).  For whatever reason, looks
> like "setup.py build" in ZODB simply ignores the existence of ZODB's
> zope/testing directory now (but doesn't ignore ZODB's other zope/*
> directories ...).
> 
> ...

The whole testing story together with all the active branches and
platforms sounds like we want to have some buildbot clients for ZODB as
well. I could set up a buildbot client on Windows 2k and Linux to test
various ZODB branches ... 

That could be added to the Zope buildbot then ... Any oppinions? 

Cheers,
Christian

-- 
gocept gmbh & co. kg - schalaunische str. 6 - 06366 koethen - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 3496 30 99 112 -
fax +49 3496 30 99 118 - zope and plone consulting and development


signature.asc
Description: This is a digitally signed message part
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev


RE: [ZODB-Dev] RE: RE: RE: PersistentMapping

2005-11-18 Thread Tim Peters
[Tim]
...
>> This worked (which is what I normally do): [build_ext -i]

[Thomas]
> It did for me too. I guess the crucial difference was doing build_ext
> instead of just build.

Yes.

> Maybe someone with more distutils clue could say something about it; if
> my guess is right, README.txt should be changed.

It's more likely due to people fiddling with zpkg.  "setup.py build" _had_
worked fine for running the tests for years, and I know it still worked fine
a few months ago.  But I don't normally do that, so didn't notice when it
broke.  It's not due to changes in ZODB code (no relevant changes have been
made there -- or at least none that I made ;-)).  For whatever reason, looks
like "setup.py build" in ZODB simply ignores the existence of ZODB's
zope/testing directory now (but doesn't ignore ZODB's other zope/*
directories ...).

...

>> I don't know what +1 means on other lists, but on this list it means
>> "that's such a good idea I'm going to devote my life to implementing it,
>> and I promise to finish it before this time next week" -- thanks ;-)

> Normalization of votes should definitely be standardized across lists.

I was pulling your leg -- +1 means the same thing here as elsewhere ("strong
yes, to the extent that I'll least argue in favor of it").

> But then, what does "implementing a deprecation" mean? If it's just
> adding a deprecation warning, I should be able to make it in time ;o)

It means adding the warning, documenting the deprecation in NEWS.txt, adding
a test to ensure that the deprecation warning is raised when appropriate,
and possibly a bunch of tedious hair to suppress the new warning(s) while
the tests that exercise the now-deprecated feature are running (while
deprecated, it's still supported until it goes away, so the tests for it
still need to run).

___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev