[Koha] Proposal to form Koha Technical Committee

[david at lang.hm]

On Fri, 19 Nov 2010, Thomas Dukleth wrote:

> On Wed, November 10, 2010 15:54, Paul Poulain wrote:
>> Le 09/11/2010 22:01, Chris Nighswonger a ?crit :
>>> On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL at critfc.org> wrote:
>>>
>
> 1.  ADVISING THE DEVELOPMENT PROCESS.
>
>>>> When the Release Manager is chosen and accepts the position, they
>> understand what they are taking on, don't they?
>>>>
>>> Just to clarify: It is *not* the responsibility of the RM to vet RFCs
>>> and pursue the critique, correction, and/or amending of them. The RM
>>> simply wields the final say over what is finally actually pushed.
>>>
>> I fully agree with you. And that's why i'm proposing to have another
>> structure/team/guy/whatever to work on strategic/long-term things.
>
<SNIP>
> If an issue is sufficiently important, a community consensus can be
> obtained which a release manager would be reluctant to oppose.  We should
> be careful not to impose an undue burden on anyone who has been willing to
> do the work of release manager.

or the person who will have to maintain the version after the initial 
release.

> We should also be careful not to mistake the 'tyranny of the majority' for
> a consensus which could clobber features used by a minority.  Remember
> that everyone is a member of the minority for something.

this is a very important point.

"I don't see a need for this" is not a valid reason to not get something 
upstream.

"this is complicated, confusing code, that interacts with all this other 
stuff that I have to maintain, and you will not be helping me maintain it" 
could be a valid reason.

Thomas is indicating that things like maintinance, documentation, taste, 
etc are not valid reasons for not merging something, but I think that the 
in some cases it may a good reason, it really depends on how intrusive the 
changes are. If it's a module that is only used if people enable that 
specific feature, the criteria is close to 'if it works, ship it', but if 
it's changes to core code, the bar to accepting is much higher.

> 2.  SOLR/LUCENE BASED RECORD INDEXING AND RETRIEVAL.
>
>>
>> To answer MJ question related to that question : I fully agree solR
>> won't probably be included in 3.4 (not ready enough,...) But do we want
>> it for 3.6 ?
>> (to answer your comment : yes we have a contract, but i'm ready, if "the
>> community" argue & decide it's a wrong idea, to reach the library and
>> explain the problem. And find a solution) But atm, I have no clear
>> decision taken, just a global feeling that "ppl think it's a good idea
>> if we succeed to address the z3950 server problem".
>
> I hope that BibLibre and others will take the following as the
> constructive criticism it is intended to be.  Everyone should be reminded
> that BibLibre and Paul Poulain's predecessor business have provided in my
> opinion the greatest share of important features for Koha without which
> most of us would not be using Koha.  Paul Poulain's business also did much
> of the most difficult early development work for Zebra.  The prospect of
> dropping Zebra support in favour of a Solr/Lucene support being developed
> by BibLibre is a major factor which has led to discussions about how to
> best manage development conflicts.
>
> I think that Solr/Lucene will prove to be the best option for local record
> indexing in Koha long term which it would not have been at the time Zebra
> support was developed for Koha.  The disagreement from me at least is only
> over how the consequences of such a change are managed.  An issue is
> whether Zebra remains available for use as an option along side
> Solr/Lucene at least until everyone is satisfied that Zebra can be
> replaced without loss of capabilities.

I would say that it would probably be a good move to make it so that both 
indexers are supported, and it would probably be a good idea to setup the 
framework so that if someone came in tomorrow with a third indexer they 
could write it to work with this framework and users could select any of 
the three at installation time (with some thought to how to convert from 
one to another after running for a while)

This is the sort of thing I was referring to when I said that someone 
proposing a change may be asked to make things more generic and flexible. 
This is also a case where the party proposing the new solution (Solr) is 
asked to modify the existing solution (Zebra) to use the new interface.

note that I know nothing about Zebra or Solr and in no way am saying that 
either is better than the other. But I am saying that moving from one 
solution to two possible solutions should be generalized into supporting 
many possible solutions.

I've heard a quote (and I have no idea who from) along the lines of

There are three interesting values in Computer Science, 0, 1, and many

we are moving from 1 to 2, moving to many is probably not a very big 
change (although doing so may require re-thinking the interface calls to 
be more generic)

>>>> And if dates slip, well, gee, won't we be getting a better release
>> due to the extra work?
>>>>
>>> Again looking at history, the type of slippage traditionally seen is
>>> terrible for users, vendors, and clients of vendors. You cannot plan
>>> around an ever-moving date.
>> ++ and i'm 10000% happy with the time-based release for 3.4 & for
>> futures versions hopefully.
>>
>> And, once again, I feel very uncomfortable when chris says : "it's the
>> decision for 3.4, the 3.6RM will decide how he want to deal with it".
>> I strongly disagree : it should a community "stable" decision a RM can't
>> change just because he want to change it.
>
> This point could just as easily be taken in the opposite way.  The
> 'community stable decision' in which everyone participated had been to
> choose Zebra in 2005 and in this case the release manager is merely acting
> to preserve people's options and not undue what had been the community
> consensus or loose a good feature even if only a minority of users are
> currently making use of it.

I have seen this same argument around time based releases happen on the 
linux-kernel lists. Several years of time based releases after many years 
of 'let the dates slip, the release will be better' seems to show pretty 
decisivly that frequent releases with what's ready at that time work 
better in practice than delaying a release until the features that were 
tagged for it are all ready.

if you delay a release until the feature is ready, there is a lot of 
preasure to declare it ready when it really isn't, because people really 
want all the other features that are in a new release.

because the releases aren't predictable, developers really want thir stuff 
to go into _this_ release because they don't know how long they will have 
to wait for the next one. If you have frequent releases, the knowledge of 
when the next release will happen (and therefor when the code will be 
upstream)

In addition, with opensource projects, the developers who aren't working 
at a particular bug are generally not working on that release, they are 
working on new features for the next release.

this leads to a cycle where

1. lots of stuff goes in to a release
2. the release gets delayed
3. more stuff goes into the next release, making more interactions, more 
new stuff to test (and have bugs)
4. the release gets delayed longer
5. goto 3

> Some people in the community could decide that some new development should
> be acceptable despite concerns about bugs and safety.

remember that is the new version of a feature (in this case Solr for 
seach) still allows the old version (zebra) to be used), the only reason 
to argue against the change is that it makes the code worse and 
reliability will suffer.