[Koha-devel] A Discussion on A Policy Setting Forth Standards of Code Submission, etc. [WAS: RFCs for 3.4 from BibLibre (serials & acquisitions)]

[LAURENT Henri-Damien]

Le 10/11/2010 07:11, Frédéric Demians a écrit :
>>
>> Because Koha's API and schema lack consistency, abstraction, and
>> isolation of concerns, adding nearly anything substantial demands that
>> those elements change in ways that affect other areas radically. The
>> amount of resources required to rebase dozens of individual feature
>> branches when half of them require meddling with the key internals in
>> way that will affect others increases in a non-linear fashion with the
>> passage of time.
> 
> I agree. Rather than forming comitees, Koha community has to deal with
> software engenering challenges. A dump (and informal) rule should impose
> to any entity adding to Koha a large new feature to do also substantial
> code rationalization and cleanup. (I don't say it's easy...)
Doing so without sharing with community members or even working in pairs
or groups with some of the parties interested on the way chosen is a
waste of time for everyone. API changes would have to be done by
concensus and could be eventually rejected and then the work done would
be nullified.
Comittee was maybe a misleading term or might not be what people think
it is. What was finally proposed in the informal meeting on the last day
was organising meetings on some technical issues in order to share work.
Working on refactoring code or Data persistance, Plack usage or work on
circular dependencies or DBIx::Class is a shared view and should be done
in the open, could have consequences on the data structure and tasks
could be quite easily be assigned to more than one company. Then charge
could be also be shared communautary and become sustainable for everyone.
a) multiple signoffs would become more evident. So integration into the
code would be also more easy. and therefore, sustainability would be
more achievable.
b) the development cost would be shared by companies.
drawbacks, it would require more time than working alone.
Any library hiring a developer to work on Koha because they believe in
the Free software,or any company (BibLibre but I think Tamil or Xercode,
or even Catalyst) want their investment not to be lost.
Even HLT have long "cried" on lost features from 1.0.
Should we consider this is not an issue ?
Friendly.
-- 
Henri-Damien LAURENT