Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
PulkoMandy: The top project in that list is primarily written in C. So that's of no real help :)
Robin Luckey: If I had to guess your CPAN coverage, I have a few clues. My repository alone covers
... [More]
about 2% of CPAN (about 300 packages) and I'd suspect there's probably in the order of 10-20 times what is in mine floating around. So I'd make an educated guess that you cover about a third of the CPAN.
jawnsy: Perl already the svn.perl.org repository that people are able to use if they wish.
But it seems that authors want a lot more control and customisation of their repository.
For example, my repository (which is one of the bigger ones) works efficiently because I've been able to tailor the hell out of it. Using the svn.perl.org repository wouldn't be useful to me.
[Less]
Frankly, code comments is something that is hard to maintain and are seldom up to date, for sure, big teams do not use them in this coding days.
Are you kidding me?
Ohloh now sees only one create commit, but two delete commits. This leads to negative line counts.
Oh dear, this sounds completely familiar to me :)
I wrote a tool years ago called cvsmonitor
... [More]
(that FishEye later cloned and made much better).
I had a fundamental bad assumption in my math that could be described as the following.
The line total at a desired point in time is equal to the known line totals at a given point, plus the sum of the deltas between the known time and the desired time
This works just fine on the trunk, but leaves you in a quandary of two choices.
EITHER
a) Track line total over time for only the trunk, ignoring all work occuring on branches.
b) Track line total over time including the branches but have incorrect totals.
Most people choose b) because it gives maximum credit for work done, and if it artificially inflates the apparent size of a project, well then most people are happy to quietly turn a blind eye.
It only really gets noticed when the totals go blatantly out of sync, or during branched deletes.
The solution, really, is that you need to track contributions, rates of change and total change DIFFERENTLY to the running line totals, because in a situation with multiple timelines the two unhook from each other.
You keep tracking change over time on branches and crediting them to contributors, but you derive the project line totals over time ONLY from the subset of changesets that occur on the trunk.
[Less]
