v0.10.16 - Onyx v2

UdjinM6 said:
Yes and No.

Yes, we should hurry as Darksend is core feature (now).

No, we should test more, just a few more hours of testing wouldn't hurt anyone but they would reveal:
1. Memory issues and crashes
2. Protocol issues and MNs delistings
and this would help us to avoid a lot of confusions

There is a HUGE amount of work Evan has done for these few days and there is a lot of changes
https://github.com/darkcoin/darkcoin/commit/8833d12a3af7d13b29079b6202ef2455971c8e34
I really respect it so why ruin it by pushing not properly tested code to mainnet?
Click to expand...
I didn't have time to get into testnet because it is true that it was super fast, but I guess Evan felt confident about the code. Besides, not everything can be seen in testnet because the sizes and number of players are so different.
 
I'm curious about the enforcement. It has been said that the changes to Darksend would not require a hard fork. So what's the point of turning enforcement off?
 
fernando said:
I didn't have time to get into testnet because it is true that it was super fast, but I guess Evan felt confident about the code. Besides, not everything can be seen in testnet because the sizes and number of players are so different.
Click to expand...
That's true, testnet differs from mainnet in terms of size and number of players. 1200 MNs vs less then 100 tMN in last test for example. But that shouldn't be "contra", that should be "pro". You can simulate any kind of (inappropriate) behavior there (forks, different kind of enforcements and even 51% attack), you can force smaller time periods for pings and other events to speed up protocol checks - however that would require to clean most of hardcoded values:wink: but that's a good thing anyway. In this situation for example dseep could be sent in 20 sec and tMNs could be removed in 70 sec of inactivity instead of 20 and 70 minutes respectively and so on.
 
Maybe there should be 2 week period when only bugs get fixed.
Jira issues is growing pretty fast.
 
AjM said:
Maybe there should be 2 week period when only bugs get fixed.
Jira issues is growing pretty fast.
Click to expand...
Current count is 34.
Jira.png
 
bituzer said:
this issue with darksend fees was most important, and its not like those 34 bugs are very important - wallet works great most of the time. and evan already made it clear that he needs more developers. so lets just be happy he gets so much work done and not tell him what to do next
Click to expand...
Sure, important bugs first i agree, but this is just bump to remember.
What is the point to make jira issues if they never get fixed?
 
donho said:
Fixed it with this: "shutdown all, delete peers.dat on local and remote, startup all, send masternode start twice a few seconds apart"
All credit goes to moocowmoo!
thanks again mate ;)
Click to expand...
Tried this and it didn't help, MN disappeared from the list after less than 60 mins.
 
AjM said:
Maybe there should be 2 week period when only bugs get fixed.
Jira issues is growing pretty fast.
Click to expand...
I don't mind immediate fix. But, upgrading all MN's immediately sounds like a bad idea. We had reports of these issues so it would be better if we were not asked to choose between upgrade or get no MN payment.
 
bituzer said:
this issue with darksend fees was most important, and its not like those 34 bugs are very important - wallet works great most of the time. and evan already made it clear that he needs more developers. so lets just be happy he gets so much work done and not tell him what to do next
Click to expand...
+1
No doubt Evan has a sense of both what he thinks is most important, and what would require the most time. It might be useful to him if MN owners took a vote listing their three most important concerns. Not as a gripe or demand on Even, but simply to give him and the other developers more data for their prioritizing.
 
Hi,

So I see that I'm not alone.
To confirm what said by Yikadee
I just made the downgrade of 1 of my MN to 15.21 : only start the deamon remote (I don't make masternode start from local)
And after few seconds I saw all my 6 MN from this MN (15.21)...
The downgrade MN : saw 1186 masternode in his list (with 1)
All the other (16.6) saw 237 or 236 MN in the list..

I will not stat my MN every hour, so just wait for the coding machine =)
 
Just my opinion... So take it for what it is worth. (I have been in the software development field for over 30 years).

Important "Production" bug fixes need to be corrected and deployed as quickly as possible to get your production system back up and running as expected. But that bug fix should only include the fix that addresses the production issue. Other small bug fixes should be rolled out through the normal release cycle only after adequate unit testing, system testing, and regression testing have been performed.

All of the recent releases have really caused a disconnect between the pools, miners and masternodes... For instance, look at the list of P2Pool (p2pools.org/drk)pools and you will quickly see that amongst the 135 or so pools running darkcoin, there are probably 6 - 8 different versions of the darkcoin daemon being run! (you can see this by sorting and reviewing the different values in the global hashrate column).

I'm ranting because, while I like all of the quick updates and bleeding edge technology... We need to fix the immediate production issue and allow all pools, miners, and MN's to get back in sync, let the dust settle, then get back to a normal release cycle!

Stop the craziness....
 
You must log in or register to reply here.
Back
Top