Development Roadmap of Bitcoin Core 0.9.2

Development Roadmap of Bitcoin Core 0.9.2
2014-04-22 14:05 ` Wladimir
  2014-04-23 20:05 ` Kristov Atlas
  
From: Warren Togami Jr. @ 2014-04-22 13:30 UTC (permalink / raw)
  To: Bitcoin Dev

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

Development Roadmap of Bitcoin Core 0.9.2

The Bitcoin Core developers have a desire to do a mostly bug-fix and
translation update release in v0.9.2. A feature and string freeze will
start about 3 weeks from now.

The purpose of this development roadmap is to communicate the project
intent and to better organize volunteers. Hopefully doing so will make
clear when particular types of contributions are most welcome and help to
push the release process forward in a more timely manner while also
improving the quality of the release.  Missing a target goal is OK. The
developers may decide to delay particular goals if there are good reasons
on a case-by-case basis. While schedules may slip, it is generally a good
thing for a goal to have existed.

Schedule (subject to change)

13 May 2014: Feature freeze.  Source string freeze.  Release candidate.

20 May 2014: Testing of a release candidate is roughly a week. More time
can be added at the discretion of the developers to allow for testing if
further release candidates are deemed necessary due to subsequent changes.

Nightly Gitian Builds

https://bitcointalk.org/index.php?topic=571414.0

To make it easier for non-developers and translators to get involved in
testing unofficial deterministic nightly builds are now available.

Translation of Bitcoin Core

https://www.transifex.com/projects/p/bitcoin/

Transifex allows open source projects a convenient way to coordinate the
work of many translators.  Periodically English language source strings
from Bitcoin Core are synchronized to the Transifex project.  Those strings
are then translated in the convenient Transifex web interface where
contributors are able to join by creating a free account.  Senior
contributors can be promoted to a Reviewer or Maintainer role for each
language.  Developers pull from Transifex to merge translated strings back
into Bitcoin Core. As a matter of policy translations are NOT accepted via
Github pull requests as those changes would be overwritten by the next
Transifex pull and there is no clean way to keep them in sync when changes
are made in both places.

https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md

The latest version of the Translation process can be found here.

Bitcoin-Translators Announce-only List

https://groups.google.com/forum/#!forum/bitcoin-translators
Bitcoin-Translators mailing list is an announce-only mailing list for
developers to communicate to translators at particular times when new
translations are needed.  Replies and discussion would go to the bitcoin
dev list.  Subscriptions to this list would additionally be valuable to the
project as it allows for a convenient way to ask for translations of other
related projects like bitcoin.org that are hosted on theTransifex platform.
 Whenever source strings of significance are changed or deadlines are
announced, translators will learn of work to be done in Transifex quickly
as they will all be subscribed to this announce list.  Discussion of
translation issues should be on the Bitcoin-Development list.

Other Improvements to the Translation process

   -

   Prior to an intended release a String Freeze is declared on a particular
   date.  The string freeze exists to ensure that translators have a
   reasonable amount of time to translate new or modified source strings so
   their work can be included in a release.
   -

   A significant issue with our past translation process was the lack of
   branch support in Transifex.  This meant that since master and v0.8.2
   diverged in May 2013, translation updates made in Transifex were not
   included in the v0.8.x stable releases until the release of v0.9.0 in early
   2014.  v0.9.1 similarly was released from a branch outside from master.
    v0.9.2 is planned to be released directly from the master branch so
   translations for this upcoming release can be developed directly.  laanwj
   came up with a great idea for dealing with future releases where we will be
   able to keep translations for both diverged stable and master branch
   simultaneously in Transifex, with scripts automating the process of merging
   strings and separating them back to the diverged branches.


Please post questions or comments about the release or translation process
here on Bitcoin-Development list. Bug reports should be posted a Github
Issues<https://github.com/bitcoin/bitcoin/issues?direction=desc&sort=updated&state=open>tickets.

Warren Togami

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

 permalink raw reply	[|nested]
2014-04-22 13:30 [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2 Warren Togami Jr.

  2014-04-23 20:05 ` Kristov Atlas
  
From: Wladimir @ 2014-04-22 14:05 UTC (permalink / raw)
  To: Warren Togami Jr.;  Bitcoin Dev

On Tue, Apr 22, 2014 at 3:30 PM, Warren Togami Jr. <wtogami@gmail•com> wrote:
> Development Roadmap of Bitcoin Core 0.9.2
>
> The Bitcoin Core developers have a desire to do a mostly bug-fix and
> translation update release in v0.9.2. A feature and string freeze will start
> about 3 weeks from now.

ACK, thanks for writing the announcement.

Wladimir



 permalink raw reply	[|nested]
2014-04-22 13:30 [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2 Warren Togami Jr.
  2014-04-22 14:05 ` Wladimir

  2014-04-23 20:28   ` Wladimir
  2014-04-23 20:39   ` Warren Togami Jr.
  
From: Kristov Atlas @ 2014-04-23 20:05 UTC (permalink / raw)
  To: bitcoin-development

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

On 04/22/2014 09:30 AM, Warren Togami Jr. wrote:
> Bitcoin-Translators mailing list is an announce-only mailing list for 
> developers to communicate to translators at particular times when new 
> translations are needed.  Replies and discussion would go to the 
> bitcoin dev list.  Subscriptions to this list would additionally be 
> valuable to the project as it allows for a convenient way to ask for 
> translations of other related projects like bitcoin.org 
> <http://bitcoin.org> that are hosted on theTransifex platform. 
>  Whenever source strings of significance are changed or deadlines are 
> announced, translators will learn of work to be done in Transifex 
> quickly as they will all be subscribed to this announce list. 
>  Discussion of translation issues should be on the Bitcoin-Development 
> list.
>
> Development Roadmap of Bitcoin Core 0.9.2
>
> The Bitcoin Core developers have a desire to do a mostly bug-fix and 
> translation update release in v0.9.2. A feature and string freeze will 
> start about 3 weeks from now.
>
>
> The purpose of this development roadmap is to communicate the project 
> intent and to better organize volunteers. Hopefully doing so will make 
> clear when particular types of contributions are most welcome and help 
> to push the release process forward in a more timely manner while also 
> improving the quality of the release.  Missing a target goal is OK. 
> The developers may decide to delay particular goals if there are good 
> reasons on a case-by-case basis. While schedules may slip, it is 
> generally a good thing for a goal to have existed.
>
>
> Schedule (subject to change)
>
> 13 May 2014:Feature freeze.  Source string freeze.  Release candidate.
>
> 20 May 2014: Testing of a release candidate is roughly a week. More 
> time can be added at the discretion of the developers to allow for 
> testing if further release candidates are deemed necessary due to 
> subsequent changes.
>
>
> Nightly Gitian Builds
>
> https://bitcointalk.org/index.php?topic=571414.0
>
> To make it easier for non-developers and translators to get involved 
> in testing unofficial deterministic nightly builds are now available.
>
>
> Warren Togami

I see that the latest nightly build (thanks for that, Warren) is still 
not compatible with Tails/Debian Squeeze. Is there still an intention to 
address this issue? Might it be fixed by 0.9.2?

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

 permalink raw reply	[|nested]
2014-04-23 20:05 ` Kristov Atlas

  2014-04-23 20:39   ` Warren Togami Jr.
  
From: Wladimir @ 2014-04-23 20:28 UTC (permalink / raw)
  To: Kristov Atlas;  Bitcoin Dev

> I see that the latest nightly build (thanks for that, Warren) is still not
> compatible with Tails/Debian Squeeze. Is there still an intention to address
> this issue? Might it be fixed by 0.9.2?

Can you be more specific as to what problem you're having?

Wladimir



 permalink raw reply	[|nested]
2014-04-23 20:05 ` Kristov Atlas
  2014-04-23 20:28   ` Wladimir

  2014-04-23 20:52     ` Kristov Atlas
  2014-04-23 22:28     ` Gregory Maxwell
  
From: Warren Togami Jr. @ 2014-04-23 20:39 UTC (permalink / raw)
  To: Kristov Atlas, Bitcoin Dev

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

On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas <kristovatlas@gmail•com>wrote:

> I see that the latest nightly build (thanks for that, Warren) is still not
> compatible with Tails/Debian Squeeze. Is there still an intention to
> address this issue? Might it be fixed by 0.9.2?
>

If I understand the situation, bitcoind does work but not bitcoin-qt due to
qt-4.6?  If that is so, then the official Bitcoin 0.8.6 binaries didn't
work on Squeeze either this is not a regression.

The priority is for bitcoind to work on as many distributions as reasonably
possible as older stable distributions are most often headless.  If you are
a rare user who needs Bitcoin-Qt on an incompatible system you can at least
build it from source.

Warren

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

 permalink raw reply	[|nested]
2014-04-23 20:39   ` Warren Togami Jr.

  2014-04-23 22:28     ` Gregory Maxwell
  
From: Kristov Atlas @ 2014-04-23 20:52 UTC (permalink / raw)
  To: Warren Togami Jr., Bitcoin Dev

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

On 04/23/2014 04:39 PM, Warren Togami Jr. wrote:
> On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas 
> <kristovatlas@gmail•com <mailto:kristovatlas@gmail•com>> wrote:
>
>     I see that the latest nightly build (thanks for that, Warren) is
>     still not compatible with Tails/Debian Squeeze. Is there still an
>     intention to address this issue? Might it be fixed by 0.9.2?
>
>
> If I understand the situation, bitcoind does work but not bitcoin-qt 
> due to qt-4.6?  If that is so, then the official Bitcoin 0.8.6 
> binaries didn't work on Squeeze either this is not a regression.
>
> The priority is for bitcoind to work on as many distributions as 
> reasonably possible as older stable distributions are most often 
> headless.  If you are a rare user who needs Bitcoin-Qt on an 
> incompatible system you can at least build it from source.
>
> Warren

Bitcoin-Qt 0.8.6 worked fine on Tails (and Debian Squeeze, I assume). 
So, it is a regression.

Here's output from the latest nightly build for Linux:

amnesia@amnesia:~/bitcoin-0.9.99.0-20140422-2bbecc8-linux/bin/32$ ./bitcoin-qt
./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: _ZN19QAbstractProxyModel11setItemDataERK11QModelIndexRK4QMapIi8QVariantE

Since Tails has many simple development tools like "make" stripped out 
for security reasons, one could not simply build from source in Tails. 
It might be possible to build in Debian Squeeze and transplant that, 
however. I'll have to give that a shot some time. I'd argue that Tails 
is an incredibly important -- and hardly obscure -- Linux distribution 
that Bitcoin should endeavour to support. See: 
https://tails.boum.org/press/index.en.html

-Kristov

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

 permalink raw reply	[|nested]
2014-04-23 20:39   ` Warren Togami Jr.
  2014-04-23 20:52     ` Kristov Atlas

  2014-04-24  1:56       ` Kristov Atlas
  2014-04-24  8:02       ` Wladimir
  
From: Gregory Maxwell @ 2014-04-23 22:28 UTC (permalink / raw)
  To: Warren Togami Jr.;  Bitcoin Dev

On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami@gmail•com> wrote:
> If you are
> a rare user who needs Bitcoin-Qt on an incompatible system you can at least
> build it from source.

Tails users usually can't really build it from source— talks is a live
boot mostly stateless linux distribution for privacy applications.
It's really good in general.

I agree that we shouldn't be statically linking QT on linux generally
(due to things like theming), though maybe we could just have the
build process dump out a seperate extra static QT binary just for
these other cases? I feel like the work maintaining it would be less
than what we've had in answering questions/complaints about it.



 permalink raw reply	[|nested]
2014-04-23 22:28     ` Gregory Maxwell

  2014-04-24  8:02       ` Wladimir
  
From: Kristov Atlas @ 2014-04-24  1:56 UTC (permalink / raw)
  To: bitcoin-development


On 04/23/2014 06:28 PM, Gregory Maxwell wrote:
> Tails users usually can't really build it from source— talks is a live
> boot mostly stateless linux distribution for privacy applications.
> It's really good in general.
>
> I agree that we shouldn't be statically linking QT on linux generally
> (due to things like theming), though maybe we could just have the
> build process dump out a seperate extra static QT binary just for
> these other cases? I feel like the work maintaining it would be less
> than what we've had in answering questions/complaints about it.
>
> ------------------------------------------------------------------------------
Dumping out a separate, extra static QT binary is a great idea.



 permalink raw reply	[|nested]
2014-04-23 22:28     ` Gregory Maxwell
  2014-04-24  1:56       ` Kristov Atlas

  2014-04-24  8:07         ` Wladimir
  2014-04-24  8:15         ` Warren Togami Jr.
  
From: Wladimir @ 2014-04-24  8:02 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Dev

On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami@gmail•com> wrote:
>> If you are
>> a rare user who needs Bitcoin-Qt on an incompatible system you can at least
>> build it from source.
>
> Tails users usually can't really build it from source— talks is a live
> boot mostly stateless linux distribution for privacy applications.
> It's really good in general.

Aside: But is Bitcoin Core a well-suited application for those uses? I
cannot imagine someone running a full node on a stateless system.

Anyhow: As this is only one symbol, we can probably get rid of it (as
we didn't use it in 0.8.6?), or put it behind some #ifdef
COMPATIBILITY_BUILD...

Another option: Instead of statically building it'd be easy enough to
build against the 4.6 Qt headers instead without even swapping the
library. Qt is, after all, forward-compatible - between the 4.x
versions. This will lose some GUI features but if compatibility is
more important here that's a choice that can be made.

Wladimir



 permalink raw reply	[|nested]
2014-04-24  8:02       ` Wladimir

  2014-04-24  8:15         ` Warren Togami Jr.
  
From: Wladimir @ 2014-04-24  8:07 UTC (permalink / raw)
  To: kristovatlas;  Bitcoin Dev

On Thu, Apr 24, 2014 at 10:02 AM, Wladimir <laanwj@gmail•com> wrote:
> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
>> On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami@gmail•com> wrote:
>>> If you are
> > Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.

Are you sure this is Qt 4.6 at all? Not Qt 4.7?

I'd expect *much* more symbols if this was a Qt 4.8 versus 4.6
conflict. Qt 4.7 introduced a lot of new things (see all the
occurences of  #if QT_VERSION >= 0x040700 - things like
setPlaceHolderText would be expected to pop up too), but 4.8 did not.

Can you check?

Wladimir



 permalink raw reply	[|nested]
2014-04-24  8:02       ` Wladimir
  2014-04-24  8:07         ` Wladimir

  2014-04-24  8:25           ` Wladimir
  
From: Warren Togami Jr. @ 2014-04-24  8:15 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev

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

On Wed, Apr 23, 2014 at 10:02 PM, Wladimir <laanwj@gmail•com> wrote:

> On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell <gmaxwell@gmail•com>
> wrote:
> > On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. <wtogami@gmail•com>
> wrote:
> >> If you are
> >> a rare user who needs Bitcoin-Qt on an incompatible system you can at
> least
> >> build it from source.
> >
> > Tails users usually can't really build it from source— talks is a live
> > boot mostly stateless linux distribution for privacy applications.
> > It's really good in general.
>
> Aside: But is Bitcoin Core a well-suited application for those uses? I
> cannot imagine someone running a full node on a stateless system.
>
> Anyhow: As this is only one symbol, we can probably get rid of it (as
> we didn't use it in 0.8.6?), or put it behind some #ifdef
> COMPATIBILITY_BUILD...
>
> Another option: Instead of statically building it'd be easy enough to
> build against the 4.6 Qt headers instead without even swapping the
> library. Qt is, after all, forward-compatible - between the 4.x
> versions. This will lose some GUI features but if compatibility is
> more important here that's a choice that can be made.
>
> Wladimir
>

I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.

It is more than one symbol.  It does not seem to be a wise thing to replace
functions beyond the trivial in glibc and libstdc++.

I personally think we need to decide upon a cut-off point beyond which it
makes no sense to add the risk of increased complexity.  RHEL6 had qt-4.6.2
as well and I don't think I've heard a single complaint about bitcoin-qt
being broken there given almost nobody uses it as a desktop.

Warren

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

 permalink raw reply	[|nested]
2014-04-24  8:15         ` Warren Togami Jr.

  2014-04-24 12:18             ` Wladimir
  
From: Wladimir @ 2014-04-24  8:25 UTC (permalink / raw)
  To: Warren Togami Jr.;  Bitcoin Dev

On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. <wtogami@gmail•com> wrote:

> I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.
>
> It is more than one symbol.  It does not seem to be a wise thing to replace
> functions beyond the trivial in glibc and libstdc++.

Qt is not part of the compiler/build environment. Thus we don't need
to resort to those kind of tricks.

As I said: we can easily build against Qt 4.6 instead. As said, that
wouldn't even need building Qt on linux, just unpacking and exporting
the headers.

But indeed we need to decide on a cut-off point. I'd have preferred
4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
Apart from tails it doesn't seem like anyone is using those old stable
distributions on the desktop.

Wladimir



 permalink raw reply	[|nested]
2014-04-24  8:25           ` Wladimir

  2014-04-25 20:09               ` Kristov Atlas
  
From: Wladimir @ 2014-04-24 12:18 UTC (permalink / raw)
  To: Warren Togami Jr.;  Bitcoin Dev

On Thu, Apr 24, 2014 at 10:25 AM, Wladimir <laanwj@gmail•com> wrote:
> On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. <wtogami@gmail•com> wrote:
>
> But indeed we need to decide on a cut-off point. I'd have preferred
> 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
> Apart from tails it doesn't seem like anyone is using those old stable
> distributions on the desktop.

Does anyone know of the timeframe in which tails will switch to a
newer version of Qt?

As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8
so is decidedly unproblematic.

I see they're working on migration at least:

- https://tails.boum.org/blueprint/Wheezy/
- https://git-tails.immerda.ch/tails/log/?h=feature/wheezy

Wladimir



 permalink raw reply	[|nested]
2014-04-24 12:18             ` Wladimir

  2014-04-25 20:47                 ` Wladimir
  
From: Kristov Atlas @ 2014-04-25 20:09 UTC (permalink / raw)
  To: bitcoin-development

Yes. Tails 1.1, based on Wheezy, will be out on June 10: 
https://tails.boum.org/contribute/calendar/

-Kristov Atlas

On 04/24/2014 08:18 AM, Wladimir wrote:
> On Thu, Apr 24, 2014 at 10:25 AM, Wladimir <laanwj@gmail•com> wrote:
>> On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. <wtogami@gmail•com> wrote:
>>
>> But indeed we need to decide on a cut-off point. I'd have preferred
>> 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
>> Apart from tails it doesn't seem like anyone is using those old stable
>> distributions on the desktop.
> Does anyone know of the timeframe in which tails will switch to a
> newer version of Qt?
>
> As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8
> so is decidedly unproblematic.
>
> I see they're working on migration at least:
>
> - https://tails.boum.org/blueprint/Wheezy/
> - https://git-tails.immerda.ch/tails/log/?h=feature/wheezy
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 permalink raw reply	[|nested]
2014-04-25 20:09               ` Kristov Atlas

  
From: Wladimir @ 2014-04-25 20:47 UTC (permalink / raw)
  To: Kristov Atlas;  Bitcoin Dev

On Fri, Apr 25, 2014 at 10:09 PM, Kristov Atlas
<author@anonymousbitcoinbook•com> wrote:
> Yes. Tails 1.1, based on Wheezy, will be out on June 10:
> https://tails.boum.org/contribute/calendar/

Thanks!

Wladimir



 permalink raw reply	[|nested]