[Koha-devel] Release Manager 3.6

[Paul Poulain]

Le 11/05/2011 19:01, Chris Cormack a écrit :
> Hi All
Hi All
> Recently I have been having a crisis of confidence.
It's exactly the same for me, as we're speaking openly.
>  I have, I hope,
> always tried to do what I think is best for the project.
It's exactly the same for me (does anyone have a doubt about that ?)
> 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.
Repeating (sorry): it's exactly the same for me.
> 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.
It's exactly the same for me: sleepless nights a a large amount of self
doubt.
I'm really not kidding.
> 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.
well, the question is not the one I asked (maybe i'm not clear enough,
sorry, in french it would be easier to say what I mean, but won't be
easier to understand for you ;-) )
(chris: I think the 4 options of your query form a kind of -unwanted-
syllogism http://en.wikipedia.org/wiki/Syllogism or sophism
-http://en.wikipedia.org/wiki/Sophism )

First of all, the question is *not* "should I resign" (maybe I agree
that you should have a break, at least during a few nights ;-) ). If I
had think you were not a good RM, I would not have suggested to be RM
for more than 1 release (see my mail on koha-devel, 2010, july, 24th
"Release Manager, How long (open question)")

The question is not either "should we abandon stability ?".
That's the underlying question you're asking, at least that's how ppl
understand it:
Owen :
> I think it would be a mistake to approve untested patches.
my opinion: 'of course it would be !'
Nicole:
> I think that a more stable Koha is in the best interests of the software and the community.
my opinion: 'of course it is !' (I must add it's in the best interests
of the libraries -and we have 100+ libraries using Koha through
BibLibre, so it's the best interests for our business ;-) )
Brendan:
> (untested patches--)
my opinion: 'of course -- !'

...

I repeat: my concern is *not* to insert "untested" patches into a public
release, not at all !
I'm saying that:
* BibLibre patches reaches bugzilla after they've been tested.
* new features stay unsigned-off for a long period, that's a pity,
unefficient, and add a lot of overhead for the submitter!

Here is the workflow we follow at BibLibre:
* for bugfixes: devA write a patch on a branch, hdl/me tests the patch
and merge it on biblibre/master (see git.biblibre.com, the only few
exceptions are really trivial patches like removing warns), apply
immediatly to customer that declared the bug, apply to everybody on next
quarterly update. If we submit the patch, can't we consider it has been
tested/validated by enough eyes ? Do we need another one ? frankly, I
don't think so !
* for new features: devA write a cool new feature sponsored by a
library. It's tested by our project manager (a librarian, that don't
know how to "sign-off" a patch !), tested by the customer/library, go
live to the customer library. Can't we consider it has been
tested/validated by enough eyes ? Do we need another one ? Worst of all:
the new feature is untested by anyone, it stays on bugzilla for
weeks/months. Then someone else submit a cool new feature that is
signed-off and merged quickly, except it overlaps with the 1st one. That
is no more applicable. So, stuff to do again and again. Just one
example: the branch 5575/5872 from BibLibre, for circulation
improvements. It has been done ... 4 times ! once sponsored by the
customer, once splitted by hdl/me before KohaCon10, once splitted again
by chris (funded by BibLibre, without library sponsorship), and,
hackfest came, we've discovered that ByWaterSolution made something
interesting for hard-due dates that ... is not compatible with this
branch (#5548). hdl takes 3 more days to work on it. And it's still not
here. This problem is *huge* for us, as we have something like 30
branches with cool new features (most if not all of them are on the
wiki). Many of them have Branch A required for branchB, required for
branchC,... imagine a second how long it will take to merge them into
official...

Back to community workflow: I see that the workflow ensure stability,
but we have completly lost agility ! And we need agility as well as
stability. Otherwise, we will end as stable as a stone, but as moving as
a stone (exaggerating a little bit, I agree ;-) )

Let me take some example again:
* really, don't you think having a security hole for ppl using CAS
(#5595) is not a problem that must be dealed *quickly* ? I say BibLibre
wrote, tested and went live with it. What do we really need more ?
* really, don't you think having a patch to fix something on LDAP not
merged for months is OK ? (see mail from Dobrica this week)
* large stuff usually requires a lot of time & conditions &
pre-requisites to be tested. The community has proven to be unable to
test "large" features (thx owen for the work you made on 5575/5872, but
it has not hit master yet...), so should we continue to ignore that fact
? (BibLibre stuff around solR is almost done, it works well, result in
huge improvements on many aspects, will anyone be able to take something
like 5 full days to setup solr and test ?)

I'm not sure I have an immediate solution. But I see there is a problem.

However, the community may decide there is no problem at all. In this
case, BibLibre is stuck with a "de facto" fork, and will have to explain
to his customers/libraries that the features they've sponsored haven't
be merged into official/master despite our efforts, so the customer has
2 solutions: drop the features, and stay with the community version or
keep the features and be a "de facto fork". None of those solutions are
good I'm sure you agree.

So, here is the final question.
Please vote:
1- Paul, OK, the problem you rise is a real one, you're a valuable
contributor, let's try to find a solution to retrieve agility (without
loosing stability)
2- Paul, shut-up, everything is perfect we don't need to change
anything. [In this case, BibLibre only option will be to explain to our
customers they've a de-facto fork and they must choose between their
features and stay "community". And that probably means we will start an
official fork, with all our cool -and stable- new stuff. Sorry, but I
don't see an other possibility]

At the end, i haven't answered chris question: I vote 1 AND 2 :
> 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
My opinion is that we won't increase the rate patches are signed off
without refining the workflow.
> 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.
Same for me: that's where my head and heart are [chris: There are so
many things we share ;-)]

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08