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

[Clay Fouts]

"Committee" in the sense that I'm reading you has the connotation of setting
aside a space and time where a group of people can focus on a specific issue
to discuss it and work toward building consensus. It seems some people have
a knee-jerk response to the word as if it's an effort to establish a
hegemonic regime bent on undercutting the release manager's role and
authority. Frankly, Koha's long-term viability depends on creating an
architectural vision more expansive than "the next release," and a working
group focussed specifically on giving that vision some formal attention is a
perfectly good way to approach that problem. Without an obvious candidate of
eminence to establish a Linus-style authority, a working group/committee is
probably the only viable approach to it.

Yes, it will generally take longer to iron out differences and to code with
an eye toward established best practices, but the extra short-term effort is
necessary for long-term strategy.

Clay


On Wed, Nov 10, 2010 at 12:41 AM, LAURENT Henri-Damien <
henridamien.laurent at gmail.com> wrote:

> 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
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20101110/ad7a17ca/attachment.htm>