[Koha-devel] "freezing" koha 3.0

[Galen Charlton]

Hi,

On Mon, May 12, 2008 at 4:08 PM, MJ Ray <mjr at phonecoop.coop> wrote:
> "Joshua Ferraro" <jmf at liblime.com> wrote: [...]
>  > This leaves open the question of who should be release manager of
>  > 3.2. I believe Galen would be in the best position of all of us to take over
>  > the role right now: [...]
>
>  Sorry for posting before reaching the end of the thread but I'd much
>  prefer the next RM to be from a different enterprise and country from
>  the last, to preserve the strengths of Koha past.  There seem to be
>  IMO at least 5 businesses trying to grow the Koha world, so if 2 of
>  them (LibLime and BibLibre) are happy to alternate for now, that would
>  be great.  It maybe also increases the incentive for those two to
>  "encourage" faster releases?

Since my name's been mentioned as a possible RM for 3.2, I'd like to
make my case.  I've been working in library software for nine years
and am familiar with library practices, particularly with respect to
metadata.  I've made a lot of contributions to Koha in the past six
months, both in terms of code and participation on the mailing lists
and IRC channel.

As Joshua mentioned, I currently work on nothing but Koha, spending
perhaps three quarters of my time on development and bugfixing and a
quarter on customer migration projects.  While I do some travel,
mostly to conferences, I would be able to devote more time to RM
duties.

I am committed to helping move the project to more frequent releases.

I agree with MJ's point - Koha is not a "benevolent dictator" sort of
project, nor limited to any one view of library practice, so I suggest
establishing a position of a secondary RM - someone who works with the
primary RM to integrate patches, would do testing and signoffs of
complicated patches, and, importantly, is designated to step in to
keep the flow of patches going when the RM is away.

This would have several advantages: if I become RM, while I do not and
will not have the level of travel that Joshua does, I do attend some
library conferences and have been known to take the odd vacation.
Having additional coverage would be useful no matter who is RM, of
course - we shouldn't require that the RM be available 365 days a
year.

Secondly, the secondary RM (or perhaps, co-RM, depending on how much
time that person spends) clearly should not come from the same
employer as the RM, and should have as much of different background as
possible.  E.g., if I'm chosen to be RM, an ideal secondary RM would
be non-USian or would work a library instead of a support vendor.
Personally, I would be happy to work with somebody from BibLibre (or
to be a secondary RM to somebody from BibLibre), particularly since I
know that both LibLime and BibLibre have ideas for large projects.
This is not to say that LibLime and BibLibre are the only current
sources for candidates for the RM position; I do feel that the RM
should be somebody who's actively and publicly working on Koha and is
familiar with the 3.x codebase.

Similarly, to spread out the workload, I think it would be a good idea
to have more than one designated QA position, i.e., one or more people
who are designated to do testing and sign off on patches.

Over the next few days, I will start sending out RFCs regarding what
LibLime is working on or plans to work on, particularly with respect
to features to be targeted for 3.2, 3.4, and perhaps 3.6.

Regards,

Galen
-- 
Galen Charlton
Koha Application Developer
LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709