Archive

Archive for the ‘Koha’ Category

Saving keystrokes when sending Koha patches

May 21st, 2010 Galen Charlton No comments

With the recent move of the Koha mailing lists to http://lists.koha-community.org/, the full email address for submitting a patch is now koha-patches@lists.koha-community.org. Since that’s a bit long to type every time you submit a patch, here’s one way to save a few keystrokes.

First, create a text file file to define a short alias for the email address. I chose to call the file ~/.git_aliases. The file should contain a line like this:

alias kpatches koha-patches@lists.koha-community.org

Next, tell Git that you want to use this address book file:

$ git config --global sendemail.aliasesfile ~/.git_aliases
$ git config --global sendemail.aliasfiletype mutt

Now, all you have to do is use kpatches in place of the full address. For example:

$ git send-email 0001-bug-4801-fix-paging-in-display-of-staged-bibs-and-im.patch
0001-bug-4801-fix-paging-in-display-of-staged-bibs-and-im.patch

Who should the emails appear to be from? [Galen Charlton ]

Who should the emails be sent to? kpatches

or

$ git send-email -to kpatches 0001-bug-4801-fix-paging-in-display-of-staged-bibs-and-im.patch
Categories: Koha Tags:

Mixed messages

May 13th, 2010 Galen Charlton 4 comments

I am glad to see that PTFS and its LibLime division have contributed the developments that PTFS has been working on for the past year or so, including features commissioned by the East Brunswick and Middletown Township public libraries and others. The text of LibLime’s announcement makes it clear that this is meant as a submission to Koha 3.2 and (more so) 3.4:

The code for the individual new features included in this version has also been made available for download from the GIT repository. The features in this release were not ready for 3.2, but, pending acceptance by the 3.4 Koha Release Manager, could be included in release 3.4.

Chris Cormack (as 3.4 release manager) and I (as 3.2 release manager) have started work on integrating this work in the Koha. Since 3.2 is in feature freeze, for the most part only the bugfixes from Harley will be included in 3.2, although I am strongly considering bringing in the granular circulation permissions work as well. The majority of the features will make their way into 3.4, although they will go through QA and discussion like any other submission.

So far, so good. As a set of contributions for 3.2 and 3.4, “Harley” represents the continuation of PTFS’ ongoing submissions of code to Koha in the past year. Further, I hope that if PTFS is serious about their push for “agile” programming, that they will make a habit of submitting works in progress for discussion and public QA sooner, as in some cases “Harley” features that were obviously completed months ago were not submitted until now.

But here is where the mixed messages come in: “Harley” is prominently listed on koha.org as a release of Koha. Since no PTFS staff are among the elected release managers or maintainers for Koha, that is overreaching. Ever since Koha expanded beyond New Zealand, no vendor has hitherto unilaterally implied that they were doing mainstream releases of Koha outside of the framework of elected release managers.

Before I go further, let me get a couple things out of the way. If somebody wants to enhance Koha and create installation packages of their work in addition to contributing their changes to the Koha project, that’s fine. In fact, if somebody wants to do that without formally submitting their changes, that’s certainly within the bounds of the GPL, although obviously I’d prefer that we have one Koha instead of a bunch of forks of it. If any library wants to download, install, test, and use “Harley”, that’s fine as well. Although there could be some trickiness upgrading from “Harley” to Koha 3.2 or Koha 3.4, it will certainly be possible to do so in the future.

What I am objecting to is the overreach.  Yes, “Harley” is important.  Yes, I hope it will help open a path to resolve other issues between PTFS/LibLime and the rest of the Koha community.  Yes, I thank PTFS for releasing the code, and in particular publishing it in their Git repository.  That doesn’t make it an official release of Koha; it is still just another contribution to the Koha project, the same as if it came from BibLibre, software.coop, Catalyst, Equinox, one of the many individual librarians contributing to Koha, or any other source.

“Harley” is available for download from LibLime’s website at http://www.liblime.com/downloads.  This is where it belongs.  Any vendor-specific distribution of Koha should be retrievable from the vendor’s own website, but it should not be presented as a formal release.  Perhaps there is room to consider having the Koha download service also offer vendor-specific distributions in addition to the main releases, but if that is desired, it should be proposed and discussed on the community mailing lists.

Updating koha.org to remove the implication that “Harley” is an official release is a simple change to make, and I call upon PTFS to do so.

Please see my disclosure statement. In particular, I am release manager for Koha 3.2 and I work for a competitor of PTFS. This post should not be construed as an official statement by Equinox, however, although I stand by my words.

Categories: Koha Tags:

Koha Git mini-tutorial: pulling from remote repostories

August 10th, 2009 Galen Charlton 1 comment

Earlier today Chris Cormack and I were chatting on IRC about various ways to manage patches, and decided to stage a little tutorial about how to pull from remote Git repositories:

<chris> speaking of public repo’s … i have been pushing to github for a while
<chris> but i have set up git-daemon on my machine at home too
<gmcharlt> chris: anything you’re ready to have me look at to pull?
<chris> not really
<chris> one interesting thing is the dbix_class branch
<chris> http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=summary
<gmcharlt> even if it’s trivial, it occurs to me that doing it and writing up how we did it might be useful material for a tutorial blog post or maiilings to koha-devel
<chris> lemme check
<chris> tell ya what
<chris> ill do a history.txt update
<chris> and commit that, and we can pull that
<chris> gmcharlt: http://git.workbuffer.org/cgi-bin/gitweb.cgi?p=koha.git;a=shortlog;h=refs/heads/documentation
<chris> so you can a remote for my repo
<chris> git remote add workbuffer.org git://git.workbuffer.org/git/koha.git
<chris> then git checkout -b documentation –track workbuffer.org/documentation
<chris> (probably need a git fetch workbuffer.org too(
<chris> then you can cherry-pick that commit over
<chris> thats one way to do it
<chris> or you could just checkout a branch
<gmcharlt> chris: yeah, I think I’ll do it as a pull
<chris> checkout -b mydocumentation
<chris> git pull workbuffer.org/documentation
<chris> i think that will do it anyway
<gmcharlt> yeah, then into my staging branch
<gmcharlt> git checkout test
<gmcharlt> git merge mydocumentation/documentation
<gmcharlt> or directly
<gmcharlt> git merge workbuffer.org/documentation
<chris> yep
<chris> i think the pull will do fetch + merge for ya
<gmcharlt> it does indeed
<gmcharlt> fetch first, though
<gmcharlt> lets you do git log –pretty=oneline test workbuffer.org/documentation
<chris> good point
<gmcharlt> chris: well, let’s make it official – send a pull request to the patches list
<chris> will do
<gmcharlt> e.g., Subject: PULL – git://git.workbuffer.org/koha.git – documentation – history changes
<gmcharlt> brief description of changes in body
<gmcharlt> something like that
<chris> works for me
<gmcharlt> “Welcome, all, to DVCS performance theatre”
<chris> off it goes
<chris> this was our first git tutorial right there .. quick someone take photos or something :-)

Categories: Koha Tags: , ,