Hi all,
I've worked a bit on filling the incubation questionnaire
and posted the results in a wiki page here:
http://geoserver.org/display/GEOS/OSGEO+incubation+questionnaire
Please contribute with additions, correction, feedback.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Nice work Andrea, much appreciated since we know you are doing this in your volunteer time. A couple of comments:
8. Please describe any relationships with commercial companies or products.
It is probably worth mentioning all the companies which have historically made significant contributions to GeoServer. The only one not there that comes to mind is Refractions.
11. Origin of the project
As I know it, GeoServer came into existence because some folks from TOPP (Vision for New York at the time?) wanted to do traffic modeling based on open source software. To do this it became evident that more then just maps were going to be needed. The data behind the map was going to have to be made available.
Around the same time the OGC the released the WFS spec as an open standard. The goals seems to line up and TOPP felt that an open source implemntation of WFS would be something of value, and also promote organizations to make their data readily available helping with the traffic modeling problem.
Might not have it quite right but that is how I understand it. Chris will undoubtedly correct me 
Andrea Aime wrote:
Hi all,
I've worked a bit on filling the incubation questionnaire
and posted the results in a wiki page here:
http://geoserver.org/display/GEOS/OSGEO+incubation+questionnairePlease contribute with additions, correction, feedback.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Nice work Andrea, much appreciated since we know you are doing this in your volunteer time. A couple of comments:
8. Please describe any relationships with commercial companies or products.
It is probably worth mentioning all the companies which have historically made significant contributions to GeoServer. The only one not there that comes to mind is Refractions.
Sure, I'll fix it.
11. Origin of the project
As I know it, GeoServer came into existence because some folks from TOPP (Vision for New York at the time?) wanted to do traffic modeling based on open source software. To do this it became evident that more then just maps were going to be needed. The data behind the map was going to have to be made available.
Around the same time the OGC the released the WFS spec as an open standard. The goals seems to line up and TOPP felt that an open source implemntation of WFS would be something of value, and also promote organizations to make their data readily available helping with the traffic modeling problem.
Might not have it quite right but that is how I understand it. Chris will undoubtedly correct me
Cool.
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?
I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Rough but quick computation (on trunk, giving up on removing white space, comments and the like):
cat `find . -name *.java` | wc -l --> 331976
cat `find . -name *.java` | wc -l --> 33885
non test code: 297991
% of test over non test: 11.3%
Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
But it's a ballpark idea, I think it's fair to assume the actual
ratio is more towards 15%-20%
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Rough but quick computation (on trunk, giving up on removing white space, comments and the like):
cat `find . -name *.java` | wc -l --> 331976
cat `find . -name *.java` | wc -l --> 33885
non test code: 297991
% of test over non test: 11.3%Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
But it's a ballpark idea, I think it's fair to assume the actual
ratio is more towards 15%-20%
Hmmm... making a better estimate is possible by removing whitespace
and comment lines. Here is an attempt trying to shave off white lines,
block comments and lines with just a comment (assuming for simplicity
that those starting with "*" are most of the time javadoc comments and lines ending with */ are also the end of a multiline block comment):
cat `find . -name *.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
183556
cat `find . -name *Test.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
24938
non test code: 158618
% of test over non test: 13.58%
Hmmm... I expected it to be higher, but it's not so bad. Most of our
tests are functional so they tend to exercise a lot of the GeoServer
code (startup, configuration, catalog access, data access, service code
and so on).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
My test code has these too.
For GeoServer app-schema, test:nontest ratio is +Inf because there is no nontest code.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
There's also the count lines of code utility (cloc: http://cloc.sourceforge.net)
This is the output for test and non test code:
non test:
$ cloc --exclude-dir=community,test .
3889 text files.
2591 unique files.
39287 files ignored.
http://cloc.sourceforge.net v 1.08 T=50.0 s (42.1 files/s, 6458.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
Java 1140 29912 71239 108562 x 1.36 = 147644.32
XSD 297 784 6694 47207 x 1.90 = 89693.30
XML 366 1352 2282 26054 x 1.90 = 49502.60
Javascript 87 902 1856 9353 x 1.48 = 13842.44
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 123 671 174 4264 x 1.90 = 8101.60
CSS 13 336 193 2693 x 1.00 = 2693.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
-------------------------------------------------------------------------------
SUM: 2106 35005 84552 203351 x 1.57 = 319986.43
-------------------------------------------------------------------------------
test:
$ cloc --exclude-dir=community,main .
2361 text files.
1698 unique files.
41930 files ignored.
http://cloc.sourceforge.net v 1.08 T=33.0 s (37.2 files/s, 4267.4 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
XSD 298 784 6698 48181 x 1.90 = 91543.90
XML 366 1272 2212 25991 x 1.90 = 49382.90
Java 248 4555 3470 18915 x 1.36 = 25724.40
Javascript 105 906 1910 9470 x 1.48 = 14015.60
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 114 602 178 4036 x 1.90 = 7668.40
CSS 14 336 193 2696 x 1.00 = 2696.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
SQL 1 5 4 31 x 2.29 = 70.99
-------------------------------------------------------------------------------
SUM: 1226 9508 16779 114538 x 1.74 = 199611.36
-------------------------------------------------------------------------------
Andrea Aime wrote:
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Rough but quick computation (on trunk, giving up on removing white space, comments and the like):
cat `find . -name *.java` | wc -l --> 331976
cat `find . -name *.java` | wc -l --> 33885
non test code: 297991
% of test over non test: 11.3%Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
But it's a ballpark idea, I think it's fair to assume the actual
ratio is more towards 15%-20%Hmmm... making a better estimate is possible by removing whitespace
and comment lines. Here is an attempt trying to shave off white lines,
block comments and lines with just a comment (assuming for simplicity
that those starting with "*" are most of the time javadoc comments and lines ending with */ are also the end of a multiline block comment):cat `find . -name *.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
183556cat `find . -name *Test.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
24938non test code: 158618
% of test over non test: 13.58%Hmmm... I expected it to be higher, but it's not so bad. Most of our
tests are functional so they tend to exercise a lot of the GeoServer
code (startup, configuration, catalog access, data access, service code
and so on).Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
This may lay out better:
http://pastebin.com/m77cc8264
Gabriel Roldan wrote:
There's also the count lines of code utility (cloc: http://cloc.sourceforge.net)
This is the output for test and non test code:
non test:
$ cloc --exclude-dir=community,test .
3889 text files.
2591 unique files.
39287 files ignored.http://cloc.sourceforge.net v 1.08 T=50.0 s (42.1 files/s, 6458.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
Java 1140 29912 71239 108562 x 1.36 = 147644.32
XSD 297 784 6694 47207 x 1.90 = 89693.30
XML 366 1352 2282 26054 x 1.90 = 49502.60
Javascript 87 902 1856 9353 x 1.48 = 13842.44
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 123 671 174 4264 x 1.90 = 8101.60
CSS 13 336 193 2693 x 1.00 = 2693.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
-------------------------------------------------------------------------------
SUM: 2106 35005 84552 203351 x 1.57 = 319986.43
-------------------------------------------------------------------------------test:
$ cloc --exclude-dir=community,main .
2361 text files.
1698 unique files.
41930 files ignored.http://cloc.sourceforge.net v 1.08 T=33.0 s (37.2 files/s, 4267.4 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
XSD 298 784 6698 48181 x 1.90 = 91543.90
XML 366 1272 2212 25991 x 1.90 = 49382.90
Java 248 4555 3470 18915 x 1.36 = 25724.40
Javascript 105 906 1910 9470 x 1.48 = 14015.60
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 114 602 178 4036 x 1.90 = 7668.40
CSS 14 336 193 2696 x 1.00 = 2696.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
SQL 1 5 4 31 x 2.29 = 70.99
-------------------------------------------------------------------------------
SUM: 1226 9508 16779 114538 x 1.74 = 199611.36
-------------------------------------------------------------------------------Andrea Aime wrote:
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Rough but quick computation (on trunk, giving up on removing white space, comments and the like):
cat `find . -name *.java` | wc -l --> 331976
cat `find . -name *.java` | wc -l --> 33885
non test code: 297991
% of test over non test: 11.3%Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
But it's a ballpark idea, I think it's fair to assume the actual
ratio is more towards 15%-20%Hmmm... making a better estimate is possible by removing whitespace
and comment lines. Here is an attempt trying to shave off white lines,
block comments and lines with just a comment (assuming for simplicity
that those starting with "*" are most of the time javadoc comments and lines ending with */ are also the end of a multiline block comment):cat `find . -name *.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
183556cat `find . -name *Test.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
24938non test code: 158618
% of test over non test: 13.58%Hmmm... I expected it to be higher, but it's not so bad. Most of our
tests are functional so they tend to exercise a lot of the GeoServer
code (startup, configuration, catalog access, data access, service code
and so on).Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
note cloc seems to be giving fairer results as it might be counting actual lines of code (ie, single lines of code taking multiple lines count as a single line of code, etc).
Gabriel Roldan wrote:
This may lay out better:
http://pastebin.com/m77cc8264Gabriel Roldan wrote:
There's also the count lines of code utility (cloc: http://cloc.sourceforge.net)
This is the output for test and non test code:
non test:
$ cloc --exclude-dir=community,test .
3889 text files.
2591 unique files.
39287 files ignored.http://cloc.sourceforge.net v 1.08 T=50.0 s (42.1 files/s, 6458.2 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
Java 1140 29912 71239 108562 x 1.36 = 147644.32
XSD 297 784 6694 47207 x 1.90 = 89693.30
XML 366 1352 2282 26054 x 1.90 = 49502.60
Javascript 87 902 1856 9353 x 1.48 = 13842.44
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 123 671 174 4264 x 1.90 = 8101.60
CSS 13 336 193 2693 x 1.00 = 2693.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
-------------------------------------------------------------------------------
SUM: 2106 35005 84552 203351 x 1.57 = 319986.43
-------------------------------------------------------------------------------test:
$ cloc --exclude-dir=community,main .
2361 text files.
1698 unique files.
41930 files ignored.http://cloc.sourceforge.net v 1.08 T=33.0 s (37.2 files/s, 4267.4 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code scale 3rd gen. equiv
-------------------------------------------------------------------------------
XSD 298 784 6698 48181 x 1.90 = 91543.90
XML 366 1272 2212 25991 x 1.90 = 49382.90
Java 248 4555 3470 18915 x 1.36 = 25724.40
Javascript 105 906 1910 9470 x 1.48 = 14015.60
JSP 71 628 1277 4371 x 1.48 = 6469.08
HTML 114 602 178 4036 x 1.90 = 7668.40
CSS 14 336 193 2696 x 1.00 = 2696.00
DTD 4 283 732 308 x 1.90 = 585.20
PHP 1 51 67 290 x 3.50 = 1015.00
DOS Batch 2 72 17 160 x 0.63 = 100.80
Bourne Shell 2 14 21 89 x 3.81 = 339.09
SQL 1 5 4 31 x 2.29 = 70.99
-------------------------------------------------------------------------------
SUM: 1226 9508 16779 114538 x 1.74 = 199611.36
-------------------------------------------------------------------------------Andrea Aime wrote:
Andrea Aime ha scritto:
Justin Deoliveira ha scritto:
One thing that I was not sure about was the usage of the svn log to
report numbers of test classes and the like. On one side, it's a way
to give a concrete information about the testing, on the other side
it might be perceived as trying to look (too) good. Opinions?I think that information would be in general good to have, I would be curious as to what the ratio of code to test code is. I guess whether we are trying to "show off" or not would depend on the numbers... for instance they may be embarrassing
Rough but quick computation (on trunk, giving up on removing white space, comments and the like):
cat `find . -name *.java` | wc -l --> 331976
cat `find . -name *.java` | wc -l --> 33885
non test code: 297991
% of test over non test: 11.3%Note this is a unfair towards test code, as non test code has
javadocs, surely more code comments, and copyright headers.
But it's a ballpark idea, I think it's fair to assume the actual
ratio is more towards 15%-20%Hmmm... making a better estimate is possible by removing whitespace
and comment lines. Here is an attempt trying to shave off white lines,
block comments and lines with just a comment (assuming for simplicity
that those starting with "*" are most of the time javadoc comments and lines ending with */ are also the end of a multiline block comment):cat `find . -name *.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
183556cat `find . -name *Test.java` | grep -v "^[ \t]*$" | grep -v "^[ \t]*//" | grep -v "^[ \t]*/\*" | grep -v "^[ \t]*\*" | grep -v ".*\*/" | wc -l
24938non test code: 158618
% of test over non test: 13.58%Hmmm... I expected it to be higher, but it's not so bad. Most of our
tests are functional so they tend to exercise a lot of the GeoServer
code (startup, configuration, catalog access, data access, service code
and so on).Cheers
Andrea
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.