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@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.
From thomas' comments, there is no community concern that this feature would be dropped in and the the developers would disappear, so the
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. maintinance, documentations, etc issues that I was listing should not be an issue. so if you create a generic 'search engine' interface and use it for Solr and modify Zebra to use it there is probably very little that could derail your work. such a interface could then have someone else create a google module (either dealing with a google search appliance, or talking to a google cloud service, or both), and it's possible that a couple years down the line someone comes up with a new search module that everyone likes so much that neither Zebra or Solr are used by anyone. If that happens, it would still be a win for this project, and for the developers who introduce Solr (because they made all the other search experimentation possible) David Lang