corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: [PROPOSAL] White-Box Releases Only
Date Mon, 22 Dec 2014 16:13:58 GMT

 -- in reply to --
From: jan i [] 
Sent: Monday, December 22, 2014 00:33
Subject: Re: [PROPOSAL] White-Box Releases Only

[ ... ]

AOO will most likely have to change something in the sources, Corinthia can
benefit from that knowledge by not building it (not sure what "it" is
specifically) into the source.

I hope long term corinthia also get a product, but The product discussion
is a bit we say in denmark, lets crawl before we walk and
think about running.

    Generally, I think one has to think forward enough to do enough to
    avoid future technical debt, but no more than that early on.
    I have an example of one "it" with regard to GUI-present materials.
    In many of the internationally-adaptable resources for dialog text
    the titles of dialog/message boxes, the AOO default English strings 
    have a %PRODUCT parameter.  Unfortunately, these default to having
    "product"-specific settings in the source release.  I would think 
    that the default should be product-indifferent, just as for the first-
    run page with title "Welcome to OpenOffice 4.1.1" and its repetition 
    in the message.  Likewise the Database Wizard dialog says "Welcome 
    to the OpenOffice Database Wizard" and so on. 

    Or don't identify the running code by a %PRODUCT in the default forms 
    of message titles and body text at all?

    That still leaves other obvious cases are the "About" box and the 
    procedure that checks for updates, in their GUI and command-line 

    Setting %PRODUCT to PRODUCT or DEFAULT or some other obvious example 
    would be an improvement for an unbranded build.  Maybe WHITE-LABEL, 
    GENERIC or UNBRANDED?  I fancy MUMBLE, though it might be a good 
    product name [;<). 

    For console applications there are similar places where identifiers 
    arise (--help responses, man pages, etc.  There I think the 
    authenticity/integrity considerations apply more than brand identify-
    cation concerns.  I don't think the importance of code provenance is
    going to be decreasing any time soon.

jan i


> Regards,
>   Andrea.

Sent from My iPad, sorry for any misspellings.

View raw message