Statistics for 3.2.6

Developers with the most changesets
Owen Leonard 9 16.1%
Chris Cormack 7 12.5%
Chris Nighswonger 7 12.5%
Nicole C. Engard 4 7.1%
Marcel de Rooy 4 7.1%
Galen Charlton 3 5.4%
Ian Walls 3 5.4%
Frédéric Demians 2 3.6%
Janusz Kaczmarek 2 3.6%
Frédérick Capovilla 2 3.6%
Paul Poulain 2 3.6%
MJ Ray 2 3.6%
Katrin Fischer 1 1.8%
Henri-Damien LAURENT 1 1.8%
Stéphane Delaune 1 1.8%
Colin Campbell 1 1.8%
Tomás Cohen Arazi 1 1.8%
Reed Wade 1 1.8%
Nahuel ANGELINETTI 1 1.8%
Robin Sheat 1 1.8%
marcel@libdevelop.rijksmuseum.nl 1 1.8%
Developers with the most changed lines
Frédéric Demians 41842 97.8%
Chris Nighswonger 417 1.0%
Galen Charlton 143 0.3%
Colin Campbell 70 0.2%
Chris Cormack 63 0.1%
Owen Leonard 43 0.1%
Nahuel ANGELINETTI 41 0.1%
Stéphane Delaune 29 0.1%
Marcel de Rooy 22 0.1%
Henri-Damien LAURENT 16 0.0%
Ian Walls 14 0.0%
Nicole C. Engard 13 0.0%
Katrin Fischer 12 0.0%
Tomás Cohen Arazi 8 0.0%
Reed Wade 8 0.0%
Robin Sheat 7 0.0%
Janusz Kaczmarek 6 0.0%
Paul Poulain 5 0.0%
Frédérick Capovilla 3 0.0%
MJ Ray 3 0.0%
marcel@libdevelop.rijksmuseum.nl 2 0.0%
Developers with the most lines removed
Frédéric Demians 11561 27.4%
Nahuel ANGELINETTI 35 0.1%
Galen Charlton 4 0.0%
Owen Leonard 1 0.0%
Developers with the most signoffs (total 127)
Chris Nighswonger 48 37.8%
Chris Cormack 41 32.3%
Nicole C. Engard 17 13.4%
Julian Maurice 3 2.4%
D Ruth Bavousett 3 2.4%
Paul Poulain 3 2.4%
Frédéric Demians 2 1.6%
Galen Charlton 2 1.6%
Jared Camins-Esakov 2 1.6%
Katrin Fischer 2 1.6%
Ian Walls 1 0.8%
Liz Rea 1 0.8%
Frère Sébastien Marie 1 0.8%
Marcel de Rooy 1 0.8%

 

Top changeset contributors by employer
(Unknown) 15 26.8%
Catalyst 9 16.1%
ACPL 9 16.1%
Foundations 7 12.5%
ByWater-Solutions 7 12.5%
Biblibre 5 8.9%
Tamil 2 3.6%
PTFS-Europe 1 1.8%
BSZ-BW 1 1.8%
Top lines changed by employer
Tamil 41848 97.8%
Foundations 422 1.0%
(Unknown) 192 0.4%
Biblibre 91 0.2%
Catalyst 78 0.2%
PTFS-Europe 70 0.2%
ACPL 46 0.1%
ByWater-Solutions 28 0.1%
BSZ-BW 12 0.0%
Employers with the most signoffs (total 127)
Foundations 48 37.8%
Catalyst 41 32.3%
ByWater-Solutions 23 18.1%
Biblibre 6 4.7%
(Unknown) 5 3.9%
Tamil 2 1.6%
BSZ-BW 2 1.6%

Playing with plackup

I spent a little time playing with plack again this weekend, first I benchmarked apache2.


Benchmarking opac.koha.workbuffer.org (be patient)
Server Software: Apache/2.2.12
Server Hostname: opac.koha.workbuffer.org
Server Port: 80
Document Path: /cgi-bin/koha/opac-main.pl
Document Length: 7754 bytes
Concurrency Level: 5
Time taken for tests: 356.021 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8113454 bytes
HTML transferred: 7754000 bytes
Requests per second: 2.81 [#/sec] (mean)
Time per request: 1780.103 [ms] (mean)
Time per request: 356.021 [ms] (mean, across all concurrent requests)
Transfer rate: 22.26 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 6 2.7 5 51
Processing: 776 1773 291.0 1768 2648
Waiting: 767 1755 290.2 1741 2642
Total: 780 1779 291.2 1772 2661
Percentage of the requests served within a certain time (ms)
50% 1772
66% 1922
75% 1986
80% 2031
90% 2149
95% 2248
98% 2406
99% 2519
100% 2661 (longest request)

Then next with nginx and plack.


Benchmarking opac.koha.workbuffer.org (be patient)
Server Software: nginx/0.7.62
Server Hostname: opac.koha.workbuffer.org
Server Port: 82
Document Path: /cgi-bin/koha/opac-main.pl
Document Length: 7737 bytes
Concurrency Level: 5
Time taken for tests: 17.453 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8087000 bytes
HTML transferred: 7737000 bytes
Requests per second: 57.30 [#/sec] (mean)
Time per request: 87.263 [ms] (mean)
Time per request: 17.453 [ms] (mean, across all concurrent requests)
Transfer rate: 452.51 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 3 7 3.6 7 22
Processing: 41 80 28.8 75 359
Waiting: 34 71 28.1 66 349
Total: 44 87 29.4 82 364
Percentage of the requests served within a certain time (ms)
50% 82
66% 92
75% 99
80% 104
90% 116
95% 125
98% 139
99% 222
100% 364 (longest request)

Looking out for your clients, long and short term

Over the years of working in software development I have come to realise that it is as important to look after your clients long term needs as it is their short term needs. It is something that is easily overlooked when you are in the throes of resolving issues that impact the client right here and now. But it is important that an equal amount of energy is spent on long term wellbeing as on getting the short term results.

In software engineering there is a concept called ‘Technical Debt’ it basically boils down to making choices that win you something in the short term, but you end up paying for in years to come. When working on a free software project this concept is still applicable, but an added dimension comes into play … lets call it ‘Social Debt’. There are often times you can make a decision that may afford you a short term gain, but may detrimentally impact the relationships with other members of the project. I posit that while Technical Debt is bad for the project as a whole, Social Debt usually hurts the debtor far more than the project. It is also far harder to recover from than Technical Debt.

Therefore I think it is in the best interests of any developers clients, that the developer takes care to not only make decisions that cause minimal Technical Debt, but also ones that cause minimal Social Debt.

Full git stats for Koha

So after the great article by Eric Hellman on his blog about the copyright to Koha code I decided to learn about subtree merging so I could combine the old koha repo, with the new one. That way instead of having the stats broken into 2 different ones, pre 2000 and post 2000, I can generate stats for the whole of the history of Koha.

Github has a great tutorial that I’m not going to repeat here. But if you follow it, you will end up with a repository that combines as many other repositories as you need.

So here’s the stats report. Some interesting things:

  • If you look at at the activity tab, you can see that we have pretty even coverage for all 24 hours of the day.
  • If you look at the general page you will see we average 3.2 commits a day .. doesn’t sound that much until you realise that is 3.2 commits average for 3755 days!!
  • Out of the last 32 weeks, there is a only a single week where commits dipped into single figures

So whatever might be happening elsewhere, main trunk development of Koha is as strong as ever. Tis good to see.

DBIx::Class and Koha

I did some work today with DBIx::Class and Koha, and got opac-account.pl partially using it.

You can see the schema here and I had to make a few changes to C4::Context, and a few to opac-account.pl.

Here is what they were.

diff --cc C4/Context.pm
index 7ba57fb,4dab9a9..cafc0ca
--- a/C4/Context.pm
+++ b/C4/Context.pm
@@@ -18,6 -18,6 +18,8 @@@ package C4::Context
use strict;
use warnings;
++use Koha::Schema;
++
use vars qw($VERSION $AUTOLOAD $context @context_stack);
BEGIN {
@@@ -191,6 -191,6 +193,27 @@@ $context = undef;        # Initially, n
=cut
++sub schema {
++    my $self = shift;
++    my $db_driver;
++    if ($context->config("db_scheme")){
++        $db_driver=db_scheme2dbi($context->config("db_scheme"));
++    }
++    else {
++        $db_driver="mysql";
++    }
++
++    my $db_name   = $context->config("database");
++    my $db_host   = $context->config("hostname");
++    my $db_port   = $context->config("port") || '';
++    my $db_user   = $context->config("user");
++    my $db_passwd = $context->config("pass");
++    my $schema = Koha::Schema->connect( "DBI:$db_driver:dbname=$db_name;host=$db_host;port=$db_port",
++      $db_user, $db_passwd);
++    return $schema;
++}
++
++
sub KOHAVERSION {
my $cgidir = C4::Context->intranetdir;
diff --cc opac/opac-account.pl
index 43a1e0c,43a1e0c..376ae98
--- a/opac/opac-account.pl
+++ b/opac/opac-account.pl
@@@ -17,16 -17,16 +17,20 @@@
# wrriten 15/10/2002 by finlay@katipo.oc.nz
# script to display borrowers account details in the opac
++# Edited by chrisc@catalyst.net.nz
use strict;
use CGI;
use C4::Members;
++use C4::Context;
use C4::Circulation;
use C4::Auth;
use C4::Output;
use C4::Dates qw/format_date/;
++use DBIx::Class::ResultClass::HashRefInflator;
use warnings;
++
my $query = new CGI;
my ( $template, $borrowernumber, $cookie ) = get_template_and_user(
{
@@@ -40,9 -40,9 +44,16 @@@
);
# get borrower information ....
--my $borr = GetMemberDetails( $borrowernumber );
++# my $borr = GetMemberDetails( $borrowernumber );
++my $context = C4::Context->new;
++my $schema = $context->schema;
++my $rs = $schema->resultset('Borrowers')->search({ borrowernumber => $borrowernumber });
++$rs->result_class('DBIx::Class::ResultClass::HashRefInflator');
++my $borr = $rs->first;
++use Data::Dumper;
++warn Dumper $borr;
my @bordat;
--$bordat[0] = $borr;
++push @bordat,$borr;
$template->param( BORROWER_INFO => @bordat );

So not many changes at all, i’ll work on changing some more, but it looks like adding DBIx::Class can be done in a gradual way.