openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer <>
Subject Re: AOO and Ohloh stats
Date Tue, 03 Dec 2013 07:53:39 GMT
On 02.12.2013 19:24, Rob Weir wrote:
> You've probably seen various social media posts, blogs, articles,
> etc., purporting to compare AOO and LO via commit statistics.  If you
> poke a little you see that these are almost always derived from Ohloh.
>   You can see our numbers here:
> It is important to keep in mind what exactly Ohloh is doing.  They are
> looking at our Subversion repository, at the source and website
> trunks, and tracking the commits made there.  But we have done our
> most-significant code in branches, not in the trunk.  All of the
> Sidebar work was done in a branch, all of the IAccesible2 work was
> done in branch and all of the 4.0.1 work was done in a branch.  That's
> how we do use Subversion:  develop new features in a branch and merge
> to the trunk when stable.
> So how does Ohloh treat this approach to version control?  As an
> example, look at how the IAccesible2 addition was treated:
> As you can see, Ohloh sees this as a single commit.  Yes, 601 files
> were modified, but it still shows up as only a single commit, because
> Ohloh only sees the merge.  It does not see the actually underlying
> development activity.
> A similar thing happened with the Sidebar feature as well.   The
> development effort was accounted for as a single commit.
> LO, on the other hand, uses a different approach with git, and every
> single one of their commits are registered by Ohloh, even if it is a
> one-line change.   So comparing AOO and LO Ohloh stats is not a valid
> comparison.
> Of course, this is not to blame Ohloh.  The fault is not in their
> service.  The fault lies with those who take such numbers and do false
> comparisons.  This is intellectually dishonest and I think we should
> point this out wherever we see it.

I am a developer and if I had to rate a bug fix or feature 
implementation solely on the number of added or modified lines of code 
then the smaller number would win.
Why would anybody think that more changes lead to better code? Maybe we 
should go the other way and identify problem hot spots in our code when 
there are more than a certain number of changes.


> Regards,
> -Rob
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message