[Bitcoin-development] Version 0.7 release planning

[Bitcoin-development] Version 0.7 release planning

[Jeff Garzik]

There seems to be consensus that we should go ahead and do a release,
before leveldb or ultraprune or anything major lands.  There is no
major landmark feature, but just a useful collection of small changes.
 It seems like a good time to Release Early, Release Often and make a
checkpoint release.

Some rough draft release notes were dumped in
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes.txt

Opening the floor...  What do we collectively want to happen, before
0.7 release?  What is the todo list for 0.7?

After cleaning out some pull requests yesterday, and looking at the
list today, I see

1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
luke-jr https://github.com/bitcoin/bitcoin/pull/1647

2) Translations update 2012-08-01 (fetched from Transifex)
Diapolo https://github.com/bitcoin/bitcoin/pull/1644

3) Add address groupings RPC from coderrr's coincontrol patches.
gmaxwell https://github.com/bitcoin/bitcoin/pull/1642

4) Add 'mempool' P2P command, and extend 'getdata' behavior
jgarzik https://github.com/bitcoin/bitcoin/pull/1641

5) PROBABLY NOT, BUT MAYBE: Relay blocks as a "preview" before
checking the transactions in them
luke-jr https://github.com/bitcoin/bitcoin/pull/1586

6) JSON-RPC method: prioritisetransaction <txid> <priority delta>
luke-jr https://github.com/bitcoin/bitcoin/pull/1583

7) HOPEFULLY: Addnode optimization and addnode access via RPC
BlueMatt https://github.com/bitcoin/bitcoin/pull/1549

8) MAYBE: Transition to requiring block height in block coinbases
gavinandresen https://github.com/bitcoin/bitcoin/pull/1526

9) WE MUST PICK ONE: RPC: lock push-down, preparing for
parallelization opportunities
jgarzik https://github.com/bitcoin/bitcoin/pull/1494
    or
RPC: add facility to enable RPCs to run outside cs_main, wallet locks
jgarzik https://github.com/bitcoin/bitcoin/pull/1493

10) I THINK WE WANT THIS?  Make IPv6 support optional again (defaults
to enabled)
luke-jr https://github.com/bitcoin/bitcoin/pull/1431

11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
luke-jr https://github.com/bitcoin/bitcoin/pull/936


Devs -- feel free to commit directly to doc/release-notes.txt if there
is a missing commit, or something that may be better described.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] Version 0.7 release planning

[Jeff Garzik]

On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> There seems to be consensus that we should go ahead and do a release,
> before leveldb or ultraprune or anything major lands.  There is no
> major landmark feature, but just a useful collection of small changes.
>  It seems like a good time to Release Early, Release Often and make a
> checkpoint release.

Procedural note:  since Gavin is on vacation, this release obviously
won't occur for at least a couple weeks.

If Gavin appears on email or IRC, though, I might try to pounce on him
and convince him to let us go ahead with 0.7-rc1, if the other devs
are happy.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com

Re: [Bitcoin-development] Version 0.7 release planning

[Gavin]

I have no objections to a rc1 happening before I'm back.

--
Gavin Andresen


On Aug 2, 2012, at 10:45 AM, Jeff Garzik <jgarzik@exmulti.com> wrote:

> On Thu, Aug 2, 2012 at 12:43 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
>> There seems to be consensus that we should go ahead and do a release,
>> before leveldb or ultraprune or anything major lands.  There is no
>> major landmark feature, but just a useful collection of small changes.
>> It seems like a good time to Release Early, Release Often and make a
>> checkpoint release.
> 
> Procedural note:  since Gavin is on vacation, this release obviously
> won't occur for at least a couple weeks.
> 
> If Gavin appears on email or IRC, though, I might try to pounce on him
> and convince him to let us go ahead with 0.7-rc1, if the other devs
> are happy.
> 
> -- 
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Version 0.7 release planning

[Luke-Jr]

On Thursday, August 02, 2012 4:43:25 PM Jeff Garzik wrote:
> Opening the floor...  What do we collectively want to happen, before
> 0.7 release?  What is the todo list for 0.7?

Based on pull-capable dev comments, I've personally noted these branches as 
accepted for 0.7:

> 7) HOPEFULLY: Addnode optimization and addnode access via RPC
> BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
> 
> 8) MAYBE: Transition to requiring block height in block coinbases
> gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
> 
> 10) I THINK WE WANT THIS?  Make IPv6 support optional again (defaults
> to enabled)
> luke-jr https://github.com/bitcoin/bitcoin/pull/1431
>
> 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
> luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor transaction/accounting time
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1393

I also personally feel these are appropriate and ready for 0.7:
> 4) Add 'mempool' P2P command, and extend 'getdata' behavior
> jgarzik https://github.com/bitcoin/bitcoin/pull/1641
> 
> 6) JSON-RPC method: prioritisetransaction <txid> <priority delta>
> luke-jr https://github.com/bitcoin/bitcoin/pull/1583
> 
> 9) RPC: add facility to enable RPCs to run outside cs_main, wallet locks
> jgarzik https://github.com/bitcoin/bitcoin/pull/1493
+
+ m) Treat generation (mined) transactions less different from receive
+ transactions
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1409

Also these, but they need testing:
> 1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
> luke-jr https://github.com/bitcoin/bitcoin/pull/1647
> 
> 5) PROBABLY NOT, BUT MAYBE: Relay blocks as a "preview" before
> checking the transactions in them
> luke-jr https://github.com/bitcoin/bitcoin/pull/1586
+
+ m) Bitcoin-Qt (Windows only): enable DEP for bitcoin-qt.exe
+ diapolo https://github.com/bitcoin/bitcoin/pull/1614

I also feel it is very important that Wumpus/laanwj decide on a name for his 
client (formerly known as Bitcoin-Qt) and add it to the software instead of 
simply claiming it is "Bitcoin" as it has for a week or so now - that change 
is anticompetitive and will confuse new users into thinking Bitcoin is the 
software too easily.

Luke

Re: [Bitcoin-development] Version 0.7 release planning

[Geir Harald Hansen]

On 02.08.2012 18:43, Jeff Garzik wrote:
> There seems to be consensus that we should go ahead and do a release,
> before leveldb or ultraprune or anything major lands.  There is no
> major landmark feature, but just a useful collection of small changes.
>  It seems like a good time to Release Early, Release Often and make a
> checkpoint release.

Looks like much goodness in this version. Thanks for all this work.

Any chance that options to limit the size of blocks and prioritize paid
vs free txes could make it in?

By the way, by far the most common support request I have at my pool is
users withdrawing coins and not seeing it in their wallet because it's
not up-to-date with the block chain. Might be worth adding something in
the bitcoin-qt GUI to make it more obvious that users can't see new
transactions and why.

> 2) Translations update 2012-08-01 (fetched from Transifex)

I just now updated the Norwegian translation on Transifex, if you'd like
to do another pull before the release. For some reason there were many
strings I had already translated that now had no translation and had to
be done again (even ones that had the same English text). Many languages
are now only about 50% translated.

Also there were new duplicated strings:

"Verify a message to ensure it was signed with a specified Bitcoin address"
"Sign a message to prove you own a Bitcoin address"
"Clear &All"

These two seem odd:
Use UPnP to map the listening port (default: 0)
Use UPnP to map the listening port (default: 1 when listening)

Regards,
Geir H. Hansen, bitminter.com

Re: [Bitcoin-development] Version 0.7 release planning

[Luke-Jr]

On Saturday, August 11, 2012 4:43:28 PM Geir Harald Hansen wrote:
> By the way, by far the most common support request I have at my pool is
> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding something in
> the bitcoin-qt GUI to make it more obvious that users can't see new
> transactions and why.

Bitcoin-Qt even delays showing generation until 2 confirms.

> These two seem odd:
> Use UPnP to map the listening port (default: 0)
> Use UPnP to map the listening port (default: 1 when listening)

The default depends on build options, so that should be correct.

Re: [Bitcoin-development] Version 0.7 release planning

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

By the way, by far the most common support request I have at my pool is

> users withdrawing coins and not seeing it in their wallet because it's
> not up-to-date with the block chain. Might be worth adding something in
> the bitcoin-qt GUI to make it more obvious that users can't see new
> transactions and why.
>

For 0.7 we've added a red "(out of sync)" warning to the balances when the
block chain is out of date.

However, due to the design of the protocol there is a large variance in
block timings, and it is not possible to determine up-to-date status with
certainty, so quite a large safety margin is used. To be precise the
warning is shown when the last received block was generated more than 90
minutes ago.

Wladimir

[-- Attachment #2: Type: text/html, Size: 950 bytes --]

Re: [Bitcoin-development] Version 0.7 release planning

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

Geir,

There were a lot of subtle changes to the English base messages such as
capitalization or punctuation, I know this is pretty annoying for
translators. It is a pity that there is no way to update all translations
when the English base message changes but not significantly enough to
trigger re-translation. I've looked but Transifex does not have that option.

Also there were new duplicated strings:
>
> "Verify a message to ensure it was signed with a specified Bitcoin address"
> "Sign a message to prove you own a Bitcoin address"
> "Clear &All"
>

Duplicate strings are not a problem. Some strings are used multiple times
in the program, and thus appear multiple times in the translation. This is
because there are cases in which a string that is the same in English is
translated differently in another language based on the context.

At least Qt translator fills duplicates in automatically, with the option
to change them if desired. I'm not sure about Transifex but I've heard it's
the same there.


>
> These two seem odd:
> Use UPnP to map the listening port (default: 0)
> Use UPnP to map the listening port (default: 1 when listening)
>

The default depends on compiler flags, hence the two messages. I suppose
the message could be split up, so that "Use UPnP to map the listening port"
is factored out.

Let's do this after 0.7.0 release though, otherwise all the translations
for those messages will be broken again. There should be no more message
changes before the release unless there is a very good reason.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1976 bytes --]

Re: [Bitcoin-development] Version 0.7 release planning

[Geir Harald Hansen]

On 11.08.2012 20:56, Wladimir wrote:
> Duplicate strings are not a problem. Some strings are used multiple
> times in the program, and thus appear multiple times in the translation.
> This is because there are cases in which a string that is the same in
> English is translated differently in another language based on the context.

That makes sense. But it's hard to translate when you just see the same
string twice and don't know the context where it will be used.

> At least Qt translator fills duplicates in automatically, with the
> option to change them if desired. I'm not sure about Transifex but I've
> heard it's the same there.

No, I just use copy and paste.

>     Use UPnP to map the listening port (default: 0)
>     Use UPnP to map the listening port (default: 1 when listening)
> 
> The default depends on compiler flags, hence the two messages. I suppose
> the message could be split up, so that "Use UPnP to map the listening
> port" is factored out.

Sorry, forgot there was a compiler flag for this. No need to split this
up. As long as there is no explanation or description for each string I
think it's easier to translate whole sentences.

On 11.08.2012 20:32, Wladimir wrote:
> By the way, by far the most common support request I have at my pool is
>
>     users withdrawing coins and not seeing it in their wallet because it's
>     not up-to-date with the block chain. Might be worth adding
something in
>     the bitcoin-qt GUI to make it more obvious that users can't see new
>     transactions and why.
>
> For 0.7 we've added a red "(out of sync)" warning to the balances when
> the block chain is out of date.

Perfect. This will prevent a lot of confusion. Thanks!

Regards,
Geir H. Hansen, bitminter.com