[Libreoffice] [Libreoffice-qa] Java 7 support in LO 3.4.5 (was: minutes of tech. steering call ...)

Lionel Elie Mamane lionel at mamane.lu
Fri Dec 9 15:43:17 PST 2011


On Sat, Dec 10, 2011 at 12:04:36AM +0100, Bjoern Michaelsen wrote:

> On Fri, Dec 09, 2011 at 11:36:47PM +0100, Lionel Elie Mamane wrote:

>> So, really, rather than "time at which the tinderbox pulled", I argue
>> that "recorded commit time of the HEAD node" is a better identifier to
>> put in tarball names, about boxes, etc. It is really (within a
>> branch) a proper global version number, à la SVN revision.

> Timesstamps are _not_ a valid reference to a source tree or order in DSCM.(*)
> Never. Not even on Sunday in moonlight.

> (*) These timestamps are set locally on developer machines, which can their
>     local time totally fubared. Using timestamps for this is
>     nonsense.

I'll grant you that a fubared local time is much more likely than a
buggy SHA-1 implementation or whatever else I can imagine. OTOH, "time
the tinderbox started this build" has IMHO *worse* problems, and
that's what is being used now, so at least we are making it
better. "Solution is not perfect, so we have to stay with even worse
solution" is not a valid line of thought for me.

More generally, I don't think that full strictness on that is worth
the added effort for *every* tester to open a cgit web page and hunt
for an arbitrary string in a long list *each* time he/she wished the
answer to the simple question of "does this build I'm running /
testing come from earlier / later / same code than this/that fix or
this/that other build".

Timestamps solve that problem in... 95%? 99%? of cases... Good enough
IMHO. We are not speaking about putting *only* the timestamp(s) as
*only* identifier, only to give them as an added information for human
convenience, not as things scripts would use as unique identifier.

-- 
Lionel


More information about the LibreOffice mailing list