Ready for release?

[Ludwig Hähne]

Hi guys,

thanks to your work, we have now implemented all of the release-critical
features listed in the issue tracker. Issue 14 is still open, but it
seems this is fixed (it works on my machine). It would be great if Jean
could test and close this issue. All developer and user tools work fine
on my machine and match the README/developer-notes descriptions.

So my question: Is there still something that you want to have
checked/implemented/worked at for the first release? Otherwise, I'd like
to branch and tag the svn trunk (as described in wiki/ReleaseTesting) so
we can start testing.

If there is something left to do, please open an issue in the Google
Code tracker with Milestone "Release0.1".

Ludwig

[Jean Brouwers]

That issue is fixed, I tested it. I will try to close it ;-)

But there is one other thing, changing the test __doc__ such that all
messages consistently start with "Test ...."

And then, we (I?) may want to undo the changes for sphinx-build as
mentioned in a previous email today.

Lastly, let's (branch the code and?) make a release candidate which we
then test on all platforms for all setup.py steps.

/Jean

[Jean Brouwers]

How to set or change the Milestone for an Issue?

/Jean

[Robert Schuppenies]

Jean Brouwers wrote:
> But there is one other thing, changing the test __doc__ such that all
> messages consistently start with "Test ...."

This is related to the docstrings of each test. We have to think
about what we want these messages to provide to us. A description of
what a test should do can also be provided in a usual code comment.
Another purpose might be to find failed tests quickly (which is by
the method name). I would favor the second one. My proposal is thus
to not provide doctests for test methods. This would result in all
messages start with "test_" (the method name).

> And then, we (I?) may want to undo the changes for sphinx-build as
> mentioned in a previous email today.

Sry, but which one do you mean?

cheers,
robert

[Ludwig Hähne]

Click "Add a comment and make changes below", then click one of the
empty label edit boxes and choose the Milestone.

[Ludwig Hähne]

Robert Schuppenies wrote on 26.11.2008 20:36:
> Jean Brouwers wrote:
>> But there is one other thing, changing the test __doc__ such that all
>> messages consistently start with "Test ...."
>
> This is related to the docstrings of each test. We have to think
> about what we want these messages to provide to us. A description of
> what a test should do can also be provided in a usual code comment.
> Another purpose might be to find failed tests quickly (which is by
> the method name). I would favor the second one. My proposal is thus
> to not provide doctests for test methods. This would result in all
> messages start with "test_" (the method name).

So you want to remove all of the doc-string for test methods, right? I'm
not in favor of that, actually. If a test fails, the filename,
method-name and line number are provided (just tried, see below).

The other purpose of the docstrings are to describe what functionality
is being tested. If a test fails, that might make it more clear which
functionality was broken/does not work (compared to a method name at least).

Ludwig

FAIL: Test object registration.
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../test_heapmonitor.py", line 63, in test_track_object
assert 1 == 0
AssertionError

[Jean Brouwers]

What I would like to see is consistent messages from all Pympler tests
when the tests are running.

My preference is to keep the current messages which show a little more
than just the "test_<name>".

/Jean

PS) I meant undo the run.py changes to look for the sphinx-build file.
Instead, treat Sphinx just like PyChecker and run
./tools/sphinx-build.py like we do ./tools/pychok.py.

[Robert Schuppenies]

Ludwig Hähne wrote:
> Robert Schuppenies wrote on 26.11.2008 20:36:
>> Jean Brouwers wrote:
>>> But there is one other thing, changing the test __doc__ such that all
>>> messages consistently start with "Test ...."
>> This is related to the docstrings of each test. We have to think
>> about what we want these messages to provide to us. A description of
>> what a test should do can also be provided in a usual code comment.
>> Another purpose might be to find failed tests quickly (which is by
>> the method name). I would favor the second one. My proposal is thus
>> to not provide doctests for test methods. This would result in all
>> messages start with "test_" (the method name).
>
> So you want to remove all of the doc-string for test methods, right? I'm
> not in favor of that, actually. If a test fails, the filename,
> method-name and line number are provided (just tried, see below).

This is true. Nevertheless I am faster seeing the name of the failed
method than the line number.

> The other purpose of the docstrings are to describe what functionality
> is being tested. If a test fails, that might make it more clear which
> functionality was broken/does not work (compared to a method name at least).

I do not propose to remove the docstrings, only change it to code
comments. When testing some functionality, it is often functionality
encapsulated in a function/method. Such a functionality includes
several tests, e.g. boundary tests which are encapsulated in a
single test method. Thus, a single docstring often doesn't hold all
information.

For me it is just a matter of taste, maybe even a bike-shed
discussion. I propose to led Jean decide. .. Okay, he just did in
favor of your proposal, Ludwig :)

[Robert Schuppenies]

Jean Brouwers wrote:
> What I would like to see is consistent messages from all Pympler tests
> when the tests are running.
>
> My preference is to keep the current messages which show a little more
> than just the "test_<name>".

So shall it rather be "check" or "test" these messages start with? I
don't mind either way.
Also we should try to make sure that test docstrings all have a
one-line summary at the beginning.

[Jean Brouwers]

As long as all are consistent. Right now there is "Test ...", "Check
...", "Verify ..." and 'test_...". I'd say all should start with
"Test ..." or "Check ..." but not both and nothing else,

/Jean

[Jean Brouwers]

FYI,

I built and tested a Pympler-0.1a1 distribution on the following platforms:

Window XP with 32-bit ActivePython 2.5.1.1 -- try + build + install + test
Window XP with 32-bit ActivePython 2.6.0.0 -- try + build + install + test

Solaris 10 with 32-bit Python 2.4.1 (built from src) -- try + build +
install + test
Solaris 10 with 32-bit Python 2.5.2 (built from src) -- try + build +
install + test

Solaris 10 with 64-bit Python 2.5.2 (built from src) -- try only
Solaris 10 with 64-bit Python 2.6b1 (built from src) -- try only

MacOS X 10.4.11 (Intel) 32-bit ActivePython 2.4.5.14 -- try + build +
install + test
MacOS X 10.4.11 (Intel) 32-bit ActivePython 2.5.2.2 -- try + build +
install + test
MacOS X 10.4.11 (Intel) 32-bit ActivePython 2.6.0.0 -- try + build +
install + test

In all cases, the pre-install tests all passed and where applicable,
the build, install and post_install tests all passed as well.

/Jean

PS) Still to do MacOS X 10.3.9 (PowerPC) 32-bit and RHEL 3 64-bit.

[Ludwig Hähne]

Hi Jean,

thanks for the extensive testing!

Please allow me to nit-pick that we have a release testing policy
described here:

http://code.google.com/p/pympler/wiki/ReleaseTesting

The purpose of this is to make sure we actually test what we are going
to upload, so that no update sneaks into the release after (or during
testing) that might break something on some platforms.

In the issue list, there are still three open issues that are marked
with a "Release1.0" milestone (I'm not sure if the 1.0 is on purpose or
if you actually meant the coming 0.1 release). I assumed the latter,
that's why I didn't create the branch yet.

If the issues are actually for 1.0, already closed or are considered
non-critical, I'll branch and tag the svn trunk as soon as possible.

Sorry again for being pedantic, but I think it will help us to better
coordinate the work we're doing.

Ludwig

[Jean Brouwers]

Understood and I do expect that we create a release candidate or beta
version and test that fully.

But I just wanted to see that there were no issues already. Also keep
in mind, several of the Python builds I have are not installed, just
compiled. So, it is only possible to run the setup.py try test and
that is not sufficient for release testing.

/Jean

My understanding of Milestone Release1.0 means the first public
release. In other words, any issues marked with Milestone Release1.0
are "must fix" for that release.

[Jean Brouwers]

I just found your earlier email and picked the wrong Milestone. They
should all be Release0.1 and I will change those. My mistake.

/Jean

[Jean Brouwers]

3 more tests passed (with very long tests times):

MacOS X 10.3.9 (PowerPC) 32-bit ActivePython 2.4.3.11 -- try + build +
install + test
MacOS X 10.3.9 (PowerPC) 32-bit ActivePython 2.5.2.2 -- try + build +
install + test
MacOS X 10.3.9 (PowerPC) 32-bit ActivePython 2.6.0.0 -- try + build +
install + test

/Jean

[Ludwig Hähne]

Ah, ok. I thought these were already meant to be release tests.

Ludwig