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/20
On Sat, Jun 14, 2014 at 7:42 AM, Un Ix wrote:
> 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
-
On Sat, Jun 14, 2014 at 7:58 AM, Un Ix wrote:
> 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/b
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" wrote:
>
>> On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote:
>> How about a prize for anyone who can spot
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
diff
How about a prize for anyone who can spot any "malicious" strings within next
hour?
;-)
> On 14/06/2014, at 1:32 pm, "Wladimir" wrote:
>
>> On Fri, Jun 13, 2014 at 10:12 PM, Jeff Garzik wrote:
>> As a general principle, I agree. Other projects have translation
>> freeze points to address thi
On Fri, Jun 13, 2014 at 10:12 PM, Jeff Garzik 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'
On Fri, Jun 13, 2014 at 3:24 PM, xor wrote:
> 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 seve
On Friday, 13 June 2014, at 9:24 pm, xor wrote:
> 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 cau
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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 havo
On Jun 13, 2014, at 1:58 PM, Wladimir wrote:
> It cannot, it is just data.
The (new) data can break user interface (at least).
--
Pavel Janík
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Soluti
It cannot, it is just data.
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 Dir
Wladimir,
On Jun 13, 2014, at 12:18 PM, Wladimir wrote:
> If I do not hear anything, I will do a last-minute language import
this import can actually break things. I'd avoid it.
--
Pavel Janík
--
HPCC Systems Open S
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 imp
14 matches
Mail list logo
