[Koha-devel] Release Manager 3.6

[Fischer, Katrin]

Hi Chris,

I totally agree with Nicole, Owen and Brendan. I also vote for:

> 1/ Continue with the current workflow, patches signed off, passed qa,
> then into master, with the goal to increase the rate patches are
> signed off

With the increasing number of patches, developments and developers having a good qa process with many
eyes checking the code and the functionality seems even more important to me than ever before.

We all have to put effort and time into that, but I think it's more than worth it.

Katrin

-----Ursprüngliche Nachricht-----
Von: koha-devel-bounces at lists.koha-community.org im Auftrag von Chris Cormack
Gesendet: Mi 11.05.2011 19:01
An: koha-devel at lists.koha-community.org
Betreff: [Koha-devel] Release Manager 3.6
 
Hi All

Recently I have been having a crisis of confidence. I have, I hope,
always tried to do what I think is best for the project. Often I do
make mistakes, a notable one happened in 2007, which I hope I in part
was rectified in 2008. But my underlying motivation with Koha has
always been to do the best for the users of the software.
In my role as Release Manager for 3.4 (and again for 3.6) what I felt
was best for the software users was a stable and well tested release.
This is something I made clear in my proposal, and which I had assumed
was understood (but you know what they say about assumptions ;)). With
the huge amount of work put in by over 80 people, I think we managed
to achieve some measure of success with that with 3.4.0 and that the
stability of the 3.2.x releases is something we can all be proud of.

Over the last couple of weeks, comments and mails both on and off list
have made me think that maybe I am out of step with what the community
desires. For 3.6 quality was still the major goal, but perhaps I have
misjudged what others want.  This has resulted in sleepless nights and
quite a large amount of self doubt.

Luckily we are still early in the 3.6 cycle, there is time to fix it.

Options as I see them
1/ Continue with the current workflow, patches signed off, passed qa,
then into master, with the goal to increase the rate patches are
signed off
2/ Refine the workflow to make signing off easier
3/ Redesign the workflow eliminating sign off (for a period, or all of
the release)
4/ Step aside to let someone else have a go at RM

As Paul has noted in another thread, I am not comfortable with
allowing patches into master untested, and I don't think I could do a
good job as RM if that were to become the case. In that case I would
rather become one of the developers submitting patches again, so
perhaps 3 and 4 are the same for me.

So, in the interest of transparency and openness, there's where my
head and heart are. I wish what is best for the users of Koha, and I
fear that maybe I am out of step.

Comments?

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110511/ef99d73c/attachment.htm>