RC3 Relaunch Strategy and Testing

thelonecrouton said:
Would it be possible to eventually separate client and masternode code so that masternodes could be upgraded / add new features without regular wallets needing to update also?
Click to expand...
Yeah, thought about that too - problem is that the 'regular wallet' is also used to mine, which is dependent on masternode election code. So currently we would have to provide three different flavours of wallets... added complexity.

- regular wallet (mining disabled)
- miner wallet (regular wallet + masternode protocol; opensource)
- masternode (miner wallet + darksend; closed source)

Maybe things simplify as soon as darksend is open sourced...
 
Once things go open, probably a lot of this will be simpler

I do like the idea of being able to push code patches - the obvious potential flaw would be someone's ability to manipulate an update to game the system. Still, I do like the idea as I am, of course, in favor of an intelligent network.

Evan, is someone capturing your development process? By that, I mean that you and the dev team have jumped through a ton of hurdles and in the process improvised a number of fork procedures. Some of these have worked well, and some... not so well. I think it is important to document this process, though, because at some point, it will be a fascinating explanation of DRK development. And, although it isn't our business to invent new ways of creating coins, I think the lessons learned from these fork attempts are really valuable to the *-coin community as a whole.
 
HammerHedd said:
Once things go open, probably a lot of this will be simpler

I do like the idea of being able to push code patches - the obvious potential flaw would be someone's ability to manipulate an update to game the system. Still, I do like the idea as I am, of course, in favor of an intelligent network.

Evan, is someone capturing your development process? By that, I mean that you and the dev team have jumped through a ton of hurdles and in the process improvised a number of fork procedures. Some of these have worked well, and some... not so well. I think it is important to document this process, though, because at some point, it will be a fascinating explanation of DRK development. And, although it isn't our business to invent new ways of creating coins, I think the lessons learned from these fork attempts are really valuable to the *-coin community as a whole.
Click to expand...
I guess all versions are in github, so anyone interested should be able to look and learn.
 
fernando said:
I guess all versions are in github, so anyone interested should be able to look and learn.
Click to expand...
I"m actually thinking more about the process rather than the code... the way to best fork a major change, etc.
We're probably watching history in the making, so I was wondering if anyone was keeping a log or anything.
 
eduffield said:
.... In the debug log, the system will complain when any issues arise and users can report such issues.....
Click to expand...


Would it be possible to get a grep command that could be periodically run over debug logs to check for complaints? I'd gladly do that for our pool node's logs, but I don't have the time required to sift through by hand.
 
You must log in or register to reply here.
Back
Top