Re: [Koha-devel] Re: Koha Work

[Pat Eyler]

On Tue, 16 Apr 2002, Roger Buck wrote:

> Hi Nicholas, I am posting a copy of this to devel list - hope that's OK.
>
> Please speak up if you think it's too much "noise" to post this kind of
> stuff to list.
>
> Nicholas Rosasco wrote:
> [--snip--]
> > I'm doing a kind of survey
> > as Chris and I are getting concerned about the problems that have popped up
> > in re releasing a next version.
> >
> > What features do you consider highest priority for Koha?
>
> 1. User access via Internet for reservations etc.
>    I think security/privacy issues would become more important!
>
> 2. Make installation more friendly, flexible and generic.
>    Koha installation should allow for "public", "member" and "intranet"
> services without requiring multiple virtual servers. File paths should
> be configurable though single config file.

This would be a huge win.  Add templating and configuration of other
features and it just gets better.

>
> 3. Better documentation - user and administration manuals required.
>    Bottom line: More documentation and reference information required at
> every level.

An installation manual and good POD in the modules for developers would be
nice here too.

>
> 4. Better Internationalisation / Integration  (standards)
>    As well as Library specific stuff, I'd like to see support for the
> most common LDAP schemas for storing user information... but more
> realistically in short term, at least make sure that whatever is done
> now for storage in SQL can be easily migrated to LDAP in future ;^)
>

LDAP would be very cool, it would be nice to verify that koha also runs on
other DBs (I'm most interested in Postgresql, but maybe someone cares
about MS SQL Server).

There are also a lot of New Zealandisms buried in koha (the ethnicity for
example).  I'd like to get those pulled out into a more configurable
package.

I already let Nicholas know about another big aim of mine, but I might as
well add it here.  I'm trying to build a solid test suite around koha
using Test::Harness.   As the test suite gets bigger, I'll be a lot more
confident about refactoring.

>
> > What features are you currently working on?
>
> 1, 2 and 3 above.
>
>
> > How extensive are they?
>
> Hmmm... still in information gathering and  a proof of concept  mode...
> but being very actively pursued on a daily basis.
>
> > What is your target for getting them done?
>
> Currently have several test systems operating - We will be going live in
> three to four weeks (max), no matter how complete/incomplete the changes
> may be at that time.
>
> > What background (if any) do you have with the library specific (MARC,
> > Z39.50) items currently under consideration?
>
> None.
>
> > The draft version short term plan is for a real/soon/now release, which will
> > become the "stable" and be turned over to a couple, with a new version being
> > "opened" as the devel in CVS -- this will start with the stuff Katipo is
> > working on for a number of clients, become a stable(probably 1.2.0), then
> > the MARC changes will start to go in with 1.3.0.  Any comments, suggestions?
> > The way documenting -- both support, and code -- is handled is due for an
> > overhaul as well -- any thoughts?
>
> Yes - I think the next release should be upgrade release only - with no
> surprises for existing uers.
>
> Proposal for new CVS provides an opprtunity to re-organise - especially
> to support more flexible installation options... and hopefuly more
> participants.
>
> I will see if I can formalise something more specific about that and
> post suggestions to the list (in next few days).

I mentioned to Nicholas that the gcc development model made some sense.
The basic idea is that we'd cut a 1.2 tree and a 1.3 tree right now, the
1.2 tree would be for bug-fixes only, while the 1.3 tree would be open for
development of new features.  After the 1.2.X tree is released, the 1.3
tree could be frozen into bug-fix mode and 1.4 opened for development.
At any given time there are three trees open, for example:
   1.2.X   general availability
   1.3.X   alpha/beta - bug fixing
   1.4.X   wide open development
As each alpha/beta version rolls into GA, the wide open version freezes
into alpha/beta and a new wide open version gets cut.

(hrrm, I think I made rather a mess of that description ... you may want
to check out the gcc.gnu.org website for a better version.)

>
> >
> > Sorry if this sounds like an inquisition, but Chris and I are trying to get
> > a handle on the who/what/where, etc.
>
> You're most welcome :-)

Thanks for opening your answers up for us all to see, think about, and add
our own bits onto.

-pate

>
> R.
>
> _______________________________________________
> Koha-devel mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>