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:

https://www.ohloh.net/p/openoffice

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:

https://www.ohloh.net/p/openoffice/commits/303139831

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.

-Andre


Regards,

-Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to