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