openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From eric b <>
Subject [OT]: [Mac OS X, Intel] some issue with Apple remote
Date Mon, 05 Dec 2011 18:48:35 GMT

Le 5 déc. 11 à 17:09, Bjoern Michaelsen a écrit :

> Hi Eric, all,

Hi Bjoern,

> I can not leave this standing as is.

Same for me : it was my time to write the code after all, and in  
return, I feel bad just because I do not see the minimalistic "thank  

>> Well, the people who know me know I'm always glad and happy to  
>> share my code, everytime I can. But this is not the first time :  
>> previous one was about the ARM assembler optimisation in  
>> interlock.c for armv7  + ISA . It was "fixed" (means my name  
>> added) after a (friendly) discussion with Jani Monoses and Björn  
>> Michaelsen.
> You are implying there was a "first time" were LibreOffice cleared  
> your name of your contribtion.

Exactly. Whatever the origin (Debian or Mars commiter or ...) it was  
commited "as it" in LibreOffice.

> This is simply not true.

Please read again : I wrote the issue was solved / fixed by you and  
Jani Monoses. Said differently "Thanks to both of you ". If you read  
something else, I'm sorry, but you misunderstood me.

> The ARM patch was upstreamed from Debian Packaging, where it was  
> already cleared of any author information or bug reference.
> It had therefore to be assumed to be of Debian origin. If you want  
> to put any blame, but it there, not on LibreOffice.

Was the code commited or not in LibreOffice at the end ?  The answer  
is : yes, it was.

So either the guy who commited the changes is responsible, or there  
is nobody who did the commit, and code without clear origin is  
included (what is basicaly not good)

> Once the truth came to light (IIRC by my Canonical co-worker Jani  
> Monoses hinting you at it, which does not exactly suggest malicious  
> intend),

That's what I wrote : "friendly".

> we very quickly contacted you to rectify the situation.

... and it was solved, I do not contest.

> Ironically, in the process of this, we discovered that recent gcc  
> versions provide better code themselves, so none of this code is  
> even used in current releases.

That's not the point.

> As the original ASM code is not even SMP-safe

When I wrote it, was Cortex A8 time, means mono-core processor, so, I  
didn't think imediately to add data memory barrier (aka dmb) , indeed.
FYI OOo4Kids svn log will show  I wrote "thanks to Jani Monoses for  
his contribution for SMP case"  (or something very close).

> and all the compilers Ubuntu use provided a better solution, I  
> could have dumped that patch -- but we left it in for vanilla gcc  
> 4.5 versions (not Ubuntus fixed one). And we (actually Jani) fixed  
> the original patch, so that it would be SMP-safe on old, non-Ubuntu  
> compilers. Looking back, I would have loved to have never touched  
> that patch at all: it created a lot of work and no extra
> value for LibreOffice on Ubuntu.

Every code has a life time. when it was written, it was usefull (and  
to my eyes it will be a while on some ARM machines). But again, this  
is not the point.

> As for the patches lifted from Apache by Thorsten: Complain to the  
> guys who maintain that nostalgic SCM at Apache to provide more  
> explicit author information.

The commiter should have read the code, verified the ownership, and  
in case of doubt, rectified : as I understood the "spirit" of the  
thing, in LibreOffice code, the real name of the author MUST appear  
for every commit.

> LibreOffice really cant be blamed if Apache publishes your work in  
> ways that do not suit you.

I have really no problem with Apache, and my motivation is to share  
and work on exciting features. I don't care if any of my  
contributions end anywhere.

But some basic rules must be respected. Thanks  [EOT for me]


Projet OOo4Kids :
L'association EducOOo :
Blog :

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message