* [Bitcoin-development] Version 0.7 release planning
@ 2012-08-02 16:43 Jeff Garzik
2012-08-02 16:45 ` Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Jeff Garzik @ 2012-08-02 16:43 UTC (permalink / raw)
To: Bitcoin Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-02 16:43 [Bitcoin-development] Version 0.7 release planning Jeff Garzik
@ 2012-08-02 16:45 ` Jeff Garzik
2012-08-02 18:00 ` Gavin
2012-08-02 17:17 ` Luke-Jr
2012-08-11 16:43 ` Geir Harald Hansen
2 siblings, 1 reply; 9+ messages in thread
From: Jeff Garzik @ 2012-08-02 16:45 UTC (permalink / raw)
To: Bitcoin Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-02 16:45 ` Jeff Garzik
@ 2012-08-02 18:00 ` Gavin
0 siblings, 0 replies; 9+ messages in thread
From: Gavin @ 2012-08-02 18:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-02 16:43 [Bitcoin-development] Version 0.7 release planning Jeff Garzik
2012-08-02 16:45 ` Jeff Garzik
@ 2012-08-02 17:17 ` Luke-Jr
2012-08-11 16:43 ` Geir Harald Hansen
2 siblings, 0 replies; 9+ messages in thread
From: Luke-Jr @ 2012-08-02 17:17 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-02 16:43 [Bitcoin-development] Version 0.7 release planning Jeff Garzik
2012-08-02 16:45 ` Jeff Garzik
2012-08-02 17:17 ` Luke-Jr
@ 2012-08-11 16:43 ` Geir Harald Hansen
2012-08-11 18:05 ` Luke-Jr
` (2 more replies)
2 siblings, 3 replies; 9+ messages in thread
From: Geir Harald Hansen @ 2012-08-11 16:43 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-11 16:43 ` Geir Harald Hansen
@ 2012-08-11 18:05 ` Luke-Jr
2012-08-11 18:32 ` Wladimir
2012-08-11 18:56 ` Wladimir
2 siblings, 0 replies; 9+ messages in thread
From: Luke-Jr @ 2012-08-11 18:05 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-11 16:43 ` Geir Harald Hansen
2012-08-11 18:05 ` Luke-Jr
@ 2012-08-11 18:32 ` Wladimir
2012-08-11 18:56 ` Wladimir
2 siblings, 0 replies; 9+ messages in thread
From: Wladimir @ 2012-08-11 18:32 UTC (permalink / raw)
To: Geir Harald Hansen; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-11 16:43 ` Geir Harald Hansen
2012-08-11 18:05 ` Luke-Jr
2012-08-11 18:32 ` Wladimir
@ 2012-08-11 18:56 ` Wladimir
2012-08-12 7:59 ` Geir Harald Hansen
2 siblings, 1 reply; 9+ messages in thread
From: Wladimir @ 2012-08-11 18:56 UTC (permalink / raw)
To: Geir Harald Hansen; +Cc: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Bitcoin-development] Version 0.7 release planning
2012-08-11 18:56 ` Wladimir
@ 2012-08-12 7:59 ` Geir Harald Hansen
0 siblings, 0 replies; 9+ messages in thread
From: Geir Harald Hansen @ 2012-08-12 7:59 UTC (permalink / raw)
To: bitcoin-development
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-08-12 7:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-02 16:43 [Bitcoin-development] Version 0.7 release planning Jeff Garzik
2012-08-02 16:45 ` Jeff Garzik
2012-08-02 18:00 ` Gavin
2012-08-02 17:17 ` Luke-Jr
2012-08-11 16:43 ` Geir Harald Hansen
2012-08-11 18:05 ` Luke-Jr
2012-08-11 18:32 ` Wladimir
2012-08-11 18:56 ` Wladimir
2012-08-12 7:59 ` Geir Harald Hansen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox