Going to tag 0.9.2 final
14 messages, 13 to 14 Jun 2014. Started by Wladimir J. van der Laan.
Wladimir J. van der Laan (5), Pavel Janík (2), Matt Whitlock (2), Un Ix (2), xor, Jeff Garzik, Mark Friedenbach
Hello,
I haven't heard of any new issues with either Bitcoin Core 0.9.2rc1 or 0.9.2rc2. This means that it is time to tag 0.9.2 final.
If you have a critical issue that you haven't reported yet please let me know as soon as possible. If I do not hear anything, I will do a last-minute language import and tag the release at the end of the (UTC) day so that gitian builds can be started.
Corrections to the release notes (https://github.com/bitcoin/bitcoin/blob/0.9.2/doc/release-notes.md) should also be submitted before then.
Thanks, Wladimir
Wladimir,
On Jun 13, 2014, at 12:18 PM, Wladimir wrote:
Quoted text (1 line)
> If I do not hear anything, I will do a last-minute language import
this import can actually break things. I'd avoid it.
It cannot, it is just data.
Wladimir
On Jun 13, 2014, at 1:58 PM, Wladimir wrote:
Quoted text (1 line)
> It cannot, it is just data.
The (new) data can break user interface (at least).
On Friday, June 13, 2014 12:18:37 PM Wladimir wrote:
Quoted text (2 lines)
> If I do not hear anything, I will do a > last-minute language import
High risk projects as Bitcoin should NOT see ANY changes between release candidates and releases.
You can cause severe havoc with ANY changes. Humans make mistakes! Please do not do such things!
On Friday, 13 June 2014, at 9:24 pm, xor wrote:
Quoted text (9 lines)
> On Friday, June 13, 2014 12:18:37 PM Wladimir wrote: > > If I do not hear anything, I will do a > > last-minute language import > > High risk projects as Bitcoin should NOT see ANY changes between release > candidates and releases. > > You can cause severe havoc with ANY changes. Humans make mistakes! > Please do not do such things!
Agreed. Does Bitcoin Core not have a release cycle policy? Typically mission-critical projects will enter a code and resource freeze prior to tagging a release candidate, after which point only critical bugfixes are allowed into the release branch. A language translation update does not qualify as a critical bugfix and should be merged during the next release cycle.
On Fri, Jun 13, 2014 at 3:24 PM, xor <xor@freenetproject•org> wrote:
Quoted text (9 lines)
> On Friday, June 13, 2014 12:18:37 PM Wladimir wrote: >> If I do not hear anything, I will do a >> last-minute language import > > High risk projects as Bitcoin should NOT see ANY changes between release > candidates and releases. > > You can cause severe havoc with ANY changes. Humans make mistakes! > Please do not do such things!
As a general principle, I agree. Other projects have translation freeze points to address this. Although it is a small holistic risk, in theory, someone could maliciously change strings at the last minute in a language maintainers don't know well.
On Fri, Jun 13, 2014 at 10:12 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
Quoted text (4 lines)
> As a general principle, I agree. Other projects have translation > freeze points to address this. Although it is a small holistic risk, > in theory, someone could maliciously change strings at the last minute > in a language maintainers don't know well.
I was just doing what was always done. In practice, the translations follow a very different cycle than the rest of the code. Entering translations as well as reviewing them happens inside Transifex.
Sure, someone could "maliciously change strings". It's typical that this little bikeshedding topic attracts so much attention.
But if it makes all of you happy I won't do the translation update.
Wladimir
How about a prize for anyone who can spot any "malicious" strings within next hour?
;-)
Quoted text (29 lines)
> On 14/06/2014, at 1:32 pm, "Wladimir" <laanwj@gmail•com> wrote: > >> On Fri, Jun 13, 2014 at 10:12 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: >> As a general principle, I agree. Other projects have translation >> freeze points to address this. Although it is a small holistic risk, >> in theory, someone could maliciously change strings at the last minute >> in a language maintainers don't know well. > > I was just doing what was always done. In practice, the translations > follow a very different cycle than the rest of the code. Entering > translations as well as reviewing them happens inside Transifex. > > Sure, someone could "maliciously change strings". It's typical that > this little bikeshedding topic attracts so much attention. > > But if it makes all of you happy I won't do the translation update. > > Wladimir > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote:
Quoted text (1 line)
> How about a prize for anyone who can spot any "malicious" strings within next hour?
I think it's more an issue of accidental breakage than any maliciousness. One character in the wrong place in a language bundle somewhere can make the difference between success and runtime failure, and it may not be immediately apparent when running in unaffected locales. This kind of problem isn't likely to result in data loss (or money loss, where money is data, is in Bitcoin), but it could be enough to necessitate scrapping the whole release, which would look bad and prompt users to question the dev team's quality control process.
Was joking, but isn't the translation process back-ended with runtime tests to ensure that any stray chars etc cause the application to fail?
Quoted text (6 lines)
> On 14/06/2014, at 1:49 pm, "Matt Whitlock" <bip@mattwhitlock•name> wrote: > >> On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote: >> How about a prize for anyone who can spot any "malicious" strings within next hour? > > I think it's more an issue of accidental breakage than any maliciousness. One character in the wrong place in a language bundle somewhere can make the difference between success and runtime failure, and it may not be immediately apparent when running in unaffected locales. This kind of problem isn't likely to result in data loss (or money loss, where money is data, is in Bitcoin), but it could be enough to necessitate scrapping the whole release, which would look bad and prompt users to question the dev team's quality control process.
Not when failure is defined as, e.g., extra text pushing a UI element down such that the button the user needs to click is no longer visible. You don't test that except by having a human being run through some example workflows, which is presumably happening during the release process.
On 06/13/2014 10:58 PM, Un Ix wrote:
Quoted text (21 lines)
> Was joking, but isn't the translation process back-ended with runtime > tests to ensure that any stray chars etc cause the application to > fail? > >> On 14/06/2014, at 1:49 pm, "Matt Whitlock" <bip@mattwhitlock•name> >> wrote: >> >>> On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote: How about a >>> prize for anyone who can spot any "malicious" strings within next >>> hour? >> >> I think it's more an issue of accidental breakage than any >> maliciousness. One character in the wrong place in a language >> bundle somewhere can make the difference between success and >> runtime failure, and it may not be immediately apparent when >> running in unaffected locales. This kind of problem isn't likely to >> result in data loss (or money loss, where money is data, is in >> Bitcoin), but it could be enough to necessitate scrapping the whole >> release, which would look bad and prompt users to question the dev >> team's quality control process. >
On Sat, Jun 14, 2014 at 7:58 AM, Un Ix <slashdevnull@hotmail•com> wrote:
Quoted text (1 line)
> Was joking, but isn't the translation process back-ended with runtime tests to ensure that any stray chars etc cause the application to fail?
There is some postprocessing done in the script that fetches translation files (see https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/update-translations.py ). It removes stray control characters, but for example there is no check for number and presence of formatting characters. I generally check that by manually looking through the diffs. But would be great if someone added that.
Wladimir
On Sat, Jun 14, 2014 at 7:42 AM, Un Ix <slashdevnull@hotmail•com> wrote:
Quoted text (3 lines)
> How about a prize for anyone who can spot any "malicious" strings within next hour? > > ;-)
Hah, if there was to be a prize I'd rather have people looking out for icebergs than for wrongly arranged deck chairs :-)
Wladimir