I second Chris's thought. There is only one community-driven OSS Koha! Thanks Massoud M. AlShareef, KnowledgeWare On Sat, Jun 4, 2011 at 1:00 PM, <koha-devel-request@lists.koha-community.org

wrote:

Send Koha-devel mailing list submissions to koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel or, via email, send a message with subject or body 'help' to koha-devel-request@lists.koha-community.org

You can reach the person managing the list at koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Koha-devel digest..."

Today's Topics:

1. Re: KOHA version 3.0, my question is about the advantages of KOHA 4 (Chris Cormack)

----------------------------------------------------------------------

Message: 1 Date: Sat, 4 Jun 2011 19:32:09 +1200 From: Chris Cormack <chris@bigballofwax.co.nz> Subject: Re: [Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4 To: Clay Fouts <cfouts@liblime.com> Cc: koha-devel@lists.koha-community.org Message-ID: <BANLkTinqDbmXc3JhvkkvZnKRKxC4GqvRog@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

...

Github makes patch submission very easy. The typical process is to fork

...

repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository. The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing

2011/6/4 Clay Fouts <cfouts@liblime.com>: the line-by-line

...

commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers.

Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences.

Right, perhaps we should move this off the Koha lists, Liblime run their own lists for their project. This discussion about how to contribute to the Liblime project is better there.

Its fairly clear from Clays message, and comments on my blog etc that what Liblime is developing is not Koha, and has diverged significantly. So I say lets just keep discussion about Koha here, and unless the discussion turns to how to reconcile the fork with the Koha project, leave discussion of Liblime's Project for their own lists. We don't discuss Koha on the Evergreen lists, and OPALS don't discuss their project on the Koha lists. Liblime have their own project with their own lists, lets leave them to it and get back to focusing on Koha.

Chris

------------------------------

_______________________________________________ Koha-devel mailing list Koha-devel@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/

End of Koha-devel Digest, Vol 67, Issue 7 *****************************************