Topic: Please test (if you dare): next-test 2013-04-12 (Read 2956 times)
Since this is posted in the general forum board, can someone explain to me like I'm five:
Are there Windows installers available with only one thing changed, or at most a group of strongly related changes? Any chance developers can decide on high-priority pull requests, and build multiple installers for people to test on their machines?
If so, is there a list of recommended things to try when testing?
Where to get testnet coins?
Does it even make sense to spend human users' time testing this, as opposed to automating testing in some way?
Are there Windows installers available with only one thing changed, or at most a group of strongly related changes? Any chance developers can decide on high-priority pull requests, and build multiple installers for people to test on their machines?
If so, is there a list of recommended things to try when testing?
Where to get testnet coins?
Does it even make sense to spend human users' time testing this, as opposed to automating testing in some way?
I'd recommend to implement something along the lines of "non-final builds of bitcoin-qt need to have mainnet explicitly enabled, just like official releases need to enable testnet explicitly".
Might make it easier for people to try out stuff like this and minimizing potential losses of "real" coins.
A con would be of course that then there would be an artificial ecosystem and bugs with mainnet (like the "database heavy blocks" hard fork recently) might be lost. The main focus on these releases seems to be something else though anyways (checking if several pull requests cause strange effects with each other).
Might make it easier for people to try out stuff like this and minimizing potential losses of "real" coins.
A con would be of course that then there would be an artificial ecosystem and bugs with mainnet (like the "database heavy blocks" hard fork recently) might be lost. The main focus on these releases seems to be something else though anyways (checking if several pull requests cause strange effects with each other).
If you look at the pull requests this seems to be the case with bitcoin too... however the bot doesn't seem to build trunk + all pull requests at once, only trunk + single pull request.
Yes, combining many pull requests is not trivial and requires a real human to do.I'm not too sure what to test with these binaries though, maybe if I "need" 2-3 features I can save on building time?
Well, the idea is you can run it as your ordinary everyday client (with the awareness that it has a lot of untested and potentially broken code) and maybe hopefully stumble upon some bug we're not thinking to test for explicitly.
If you look at the pull requests this seems to be the case with bitcoin too... however the bot doesn't seem to build trunk + all pull requests at once, only trunk + single pull request.
I'm not too sure what to test with these binaries though, maybe if I "need" 2-3 features I can save on building time?
On a different note, is there a buildbot that one can run and that would somehow help devs? I don't mind donating some CPU time and space for a VM that builds and tests builds automatically in the background if it means having a better/more stable client...
I'm not too sure what to test with these binaries though, maybe if I "need" 2-3 features I can save on building time?
On a different note, is there a buildbot that one can run and that would somehow help devs? I don't mind donating some CPU time and space for a VM that builds and tests builds automatically in the background if it means having a better/more stable client...
I'm not really sure how you devs are organized, but at another project I'm working on we have a patchbot. Translated to this here, it would make a new build every time a new changeset is posted to a pull request. Then it runs the test suite. If it passes, it reports back to the pull request and provides a link to download this specific binary.
That's exactly what the Pull Tester Gavin mentioned does already...
I'm not really sure how you devs are organized, but at another project I'm working on we have a patchbot. Translated to this here, it would make a new build every time a new changeset is posted to a pull request. Then it runs the test suite. If it passes, it reports back to the pull request and provides a link to download this specific binary.
For the record:
I think testing a gazillion pulls at once is madness, because if something doesn't work it can be incredibly difficult to figure out which of the gazillion changes made it break. Assuming that just once change made it break and not some subtle interaction between two or three or six changes...
If you want to help test, I think it would be much more helpful if you find a feature you care about, grab the binaries that the pull-tester creates, test thoroughly, and then report results in the pull request on github.
Agree too many things .... I think testing a gazillion pulls at once is madness, because if something doesn't work it can be incredibly difficult to figure out which of the gazillion changes made it break. Assuming that just once change made it break and not some subtle interaction between two or three or six changes...
If you want to help test, I think it would be much more helpful if you find a feature you care about, grab the binaries that the pull-tester creates, test thoroughly, and then report results in the pull request on github.
If you want to help test, I think it would be much more helpful if you find a feature you care about, grab the binaries that the pull-tester creates, test thoroughly, and then report results in the pull request on github.
Indeed, thorough testing of individual pull requests is by far better (and safer). 
For the record:
I think testing a gazillion pulls at once is madness, because if something doesn't work it can be incredibly difficult to figure out which of the gazillion changes made it break. Assuming that just once change made it break and not some subtle interaction between two or three or six changes...
If you want to help test, I think it would be much more helpful if you find a feature you care about, grab the binaries that the pull-tester creates, test thoroughly, and then report results in the pull request on github.
I think testing a gazillion pulls at once is madness, because if something doesn't work it can be incredibly difficult to figure out which of the gazillion changes made it break. Assuming that just once change made it break and not some subtle interaction between two or three or six changes...
If you want to help test, I think it would be much more helpful if you find a feature you care about, grab the binaries that the pull-tester creates, test thoroughly, and then report results in the pull request on github.
next-test is a branch of the master bitcoind & Bitcoin-Qt code with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details).
Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLET
Today's next-test includes the following pull requests (green are merged now; red are disputed):
- Parse URIs with non-BTC amounts
- -acceptnonstdtxn option to skip "non-standard transaction" checks
- Support for Tonal Bitcoin units (ᵇTBC, ˢTBC, and TBC)
- getblocktemplate: longpolling support
- JSON-RPC method: prioritisetransaction
- A set of build scripts on top of gitian and vagrant for automating gitian builds...
- Change window titles to "Bitcoin-Qt -
" / misc related renames - Specify fees explicitly via JSON-RPC
- CreateNewBlock: Child-pays-for-parent / Add transaction fee later
- Add small-data OP_DROP transactions as standard transactions.
- FreeBSD and OpenBSD build fixes
- Support for specific BIP 22 rejection reasons and BIP 23 block proposal
- Base58 en-/de-coding
- Fixes for when listtransactions encounters non-standard outputs
- let user select wallet file with -wallet=foo.dat
- Add wget(1)-friendly crypted key dump via GET /wallet-ckeys.json
- RPC: Avoid cleartext passwords by default
- Restore FIRST_CLASS_MESSAGING
- Addition of Import Private Key Menu
- Use Hal's optimized secp256k1 verifier
- P2P: do not return addresses older than 7 days in "addr" messages
- listreceivedbyaddress now provides tx ids (issue #1149)
- Watch-Only Addresses: Separating Transaction Signing From Transaction Processing
- break after ProcessMessage() to give other peers a chance.
- Update for the Windows Installer
- wallet encapsulation
- Only create signatures with even S, and verification mode to check.
- Added comments to sync.h to make it easier to understand the macros
- Added configure scripts.
- Wallet registration locks in main.cpp + UnregisterAllWallet() function
- Support for building against system LevelDB
- Optimize OP_CHECKMULTISIG signature hashing
- Filter listaddressgroupings
- remove duplicate bitdb.Open() code from init
- Discourage fee sniping with nLockTime
- Fix off-by-one errors in the interpretation of IsFinal()
- Yet another Coin Control Release
- Accept negative -par values to leave N CPUs free.
- Block uneconomic UTXO creation
- Added -txnotify to call a script when a transaction is received
- Allow createrawtransaction to accept duplicate addresses
- Add user interface to set dust limit and filtered addresses
- Fix LevelDB removing /dev/null at build time
- Added CWalletManager class to support loading of multiple wallets.
- Make explicitly requested salvage operations keep going when there is an error.
- Network activity toggle
- update dependency-libs for Gitian builds
- 0mq - Zero MQ Support.
- Use a uint256 for bnChainWork
- Adding blockhash parameter to getrawtransaction - Issue #2077
- Bitcoin-Qt: full Qt5 support
- Bitcoin-Qt: remove " - " on empty title in BitcoinGUI::message()
- Add -lboost_chrono to both the qt .pro file and makefile.unix
- new splash screen
- rework ClientModel::getBlockSource() + BitcoinGUI::setNumBlocks()
- qt: don't show rpcconnect command line option in help
Jump to: