On Wednesday 22 February 2006 10:58, Dominik Huber wrote:
Do you have an other solutions for this problem?
Honestly, I had not thought about this case, but it is clearly a valid use
case.
What about this structure?
repos/main/
NAMESPACE/
branches/
tags/
trunk/
Stephan Richter wrote:
On Wednesday 22 February 2006 10:58, Dominik Huber wrote:
Do you have an other solutions for this problem?
Honestly, I had not thought about this case, but it is clearly a valid use
case.
What about this structure?
repos/main/
NAMESPACE/
Dominik Huber wrote:
We came up with the same solution first. But our problem appears within
the following use case.
A few developers are sharing code on application level (not package
level!) for different dedicated customer projects. They have problems to
setup identical dev-environments
Benji York wrote:
Dominik Huber wrote:
We came up with the same solution first. But our problem appears
within the following use case.
A few developers are sharing code on application level (not package
level!) for different dedicated customer projects. They have problems
to setup
On Mon, Feb 20, 2006 at 04:31:03PM -0500, Stephan Richter wrote:
Hi Stephan,
This seems to me a great step forward but I am missing something.
The quality is measured by a number of metrics, but it seems nowhere is
actually measured if the software does what it is supposed to do, if it is
Lennart Regebro wrote:
[snip]
tests (in doctest format)
This seems like a very random requirement for me. I'd like to see
tests that can be run with the standard test-runner, otherwise I don't
see a reason to restrict it. I find doctest greating for testing docs,
and testing longer use cases.
On Tuesday 21 February 2006 05:59, Reinoud van Leeuwen wrote:
This seems to me a great step forward but I am missing something.
The quality is measured by a number of metrics, but it seems nowhere is
actually measured if the software does what it is supposed to do, if it is
clear how it works
I hate to cross-post this, but would it be possible to limit this
discussion to a single list (e.g. zope3-dev, maybe)? I'm interested
in this topic, but my mail client isn't smart enough to filter it out
to only one place and I'm sure there are a lot of other people with
the same issue.
On Tuesday 21 February 2006 06:09, Lennart Regebro wrote:
First, about the IP: The idea that we can use the same certification
process for different repositories and different code owners is
interesting. In that case, there could be a common
listing/certification site, covering several
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
On Tuesday 21 February 2006 05:59, Reinoud van Leeuwen wrote:
This seems to me a great step forward but I am missing something.
The quality is measured by a number of metrics, but it seems nowhere is
actually measured if the software does
On Tuesday 21 February 2006 10:33, Lennart Regebro wrote:
1. Having at least one reasonably complete usage example.
2. All code examples in the documentation should be in doctest format,
and included as a part of the standard test-run.
(Maybe you had these in there and I forgot about them,
Thanks for the answer. I only have one remaining comment, then, about testing:
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
Why is it random? It is taken straight from the conventions now used in Zope 3
for all new development. The rationale behind it is that you are forced to
document
On Tuesday 21 February 2006 11:02, Lennart Regebro wrote:
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
Why is it random? It is taken straight from the conventions now used in
Zope 3 for all new development. The rationale behind it is that you are
forced to document and reason all
Lennart Regebro wrote:
Thanks for the answer. I only have one remaining comment, then, about
testing:
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
Why is it random? It is taken straight from the conventions now
used in Zope 3 for all new development. The rationale behind it is
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
Most testing I do is not about handling cases at all, it's about
testing specific functionality, making sure that old bugs doesn't pop
up again and stuff like that. Most of these tests would in doctest
format provide no documentation at
On 2/21/06, Benji York [EMAIL PROTECTED] wrote:
Again, not for the average user, bit if the hypothetical six month bug
were found and those tests were decently written doctests, it would be
much easier for the maintainer to follow what the test was doing.
Maybe an example can help. Because I
On Tuesday 21 February 2006 11:59, Lennart Regebro wrote:
Well, a doctest could explain the migration test and what has changed.
Nothing changed. It's two different calendar products. It's
basically an import/export from the old calendar to the new. There is
nothing to explain.
If nothing
Lennart Regebro wrote:
On 2/21/06, Benji York [EMAIL PROTECTED] wrote:
Again, not for the average user, bit if the hypothetical six month bug
were found and those tests were decently written doctests, it would be
much easier for the maintainer to follow what the test was doing.
Maybe an
On 2/21/06, Stephan Richter [EMAIL PROTECTED] wrote:
If nothing changed, then you need no tests. Of course things changed. The data
structures changed. And the migration test is a wonderful opportunity to
document those data structure changes.
*sigh* Could you please try to read what I wrote?
On Tuesday 21 February 2006 12:14, Lennart Regebro wrote:
...for a maintainer. I also completely fail to see how the latter
format gives anybody any extra insight, or how this provides any sort
of documentation.
Of course this does not provide any benefit, because you did not document the
20 matches
Mail list logo
