[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netsukuku-vala] Planning test
From: |
Ricardo Lanziano |
Subject: |
Re: [Netsukuku-vala] Planning test |
Date: |
Sat, 13 Jul 2013 16:16:43 -0005 |
On Sat, Jul 13, 2013 at 5:19 AM, Luca Dionisi <address@hidden> wrote:
First, I am not sure it is a good move. It depends on the size of the community.
The program is unstable and could very well block the network for a
number of reasons.
If the network is large and many users rely on it for their daily
communication needs, then this test will probably result in a bad
reputation for netsukuku. On the other hand, if the users are aware of
the tests going on and are willing to have a temporarily broken
network, then go ahead.
What IP ranges do they use for the networks? Maybe we can coexist.
Do they use the network to get Internet access?
Sorry, I explained myself wrong. We were planning to use the hardware
only, not their current network, were going to test ntk only. Since he
program is currently unstable, that is exactly what I want to test: trying
to get ntk running for a while (ntk network exclusive) and see if it
crashes somewhere to get some stack traces and debug it further.
Second, I have no testing plans at the moment. Proceed with any test
plan you can imagine. Take note of what you want to verify and the
steps you follow.
Yes, since I have very little knowledge of the current code I was
thinking was to try to test it in real hardware nodes and catch and
report the finded bugs.
Also, I want to take the opportunity to verify the interface wrapper
for GNU/Linux, you know, entering and leaving the network, etc.
stress testing.
Third, I am interested mainly in proving that the protocol works
correctly and does scale. Optimizations for the wireless world, I will
face this problem later.
Yes me too, I am letting those issues to the wireless gurus aswell.
So, for recap:
1) There would be a test network only, we are only interesting in
testing ntk in real wireless equipment and nodes (OpenWRT, etc)
2) The plan is to review all the bugs that pop up during the testing,
write them on the bug tracker and start the hunting.
3) There would be no wireless annotations, that would be the job
for the wireless gurus.