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
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
This option has my vote. I think it would be a mistake to approve untested patches. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Wed, May 11, 2011 at 11:03 PM, Owen Leonard <oleonard@myacpl.org> wrote:
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
This option has my vote. I think it would be a mistake to approve untested patches.
+1. -- Indranil Das Gupta Phone : +91-98300-20971 Blog : http://indradg.randomink.org/blog IRC : indradg on irc://irc.freenode.net Twitter : indradg -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=- Please exchange editable Office documents only in ODF Format. No other format is acceptable. Support Open Standards. For a free editor supporting ODF, please visit LibreOffice - http://www.documentfoundation.org
On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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
This is my vote! I know it takes more work and more time for features to be approved, but I'm for a more stable, tested Koha. That said, I am most certainly not for option #4. Chris has done amazing things for Koha, for open source, and for me personally. Without your efforts Chris I wouldn't be a Koha community member today and would have never thought to help get the manual off the ground. I agree that you do look out for the best interests of Koha and I think that a more stable Koha is in the best interests of the software and the community. Nicole
On 5/11/2011 1:38 PM, Nicole Engard wrote:
On Wed, May 11, 2011 at 1:01 PM, Chris Cormack<chris@bigballofwax.co.nz> wrote:
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 This is my vote! I know it takes more work and more time for features to be approved, but I'm for a more stable, tested Koha. Nicole says it spot-on; the current process requires some more time, but it is *well* worth it, in terms of a running product, IMO. +1 for option 1.
I also strongly approve of Chris's leadership of this transition phase--you've done a great job, Chris. It's been an adjustment, for everyone, getting to the slightly-more-challenging process, but most folks I have talked to feel that it does make for a better product. -- *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software VISIT US AT ALA: BOOTH 732 Headquarters: Santa Barbara, CA Office: Washington, DC Phone/Fax (888)900-8944 http://bywatersolutions.com ruth@bywatersolutions.com
+1 for 1/ and for Chris Cormack. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gary L. Harris, M.L.S. M.A. Director, Technical Services Bureau New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 (505) 476-9730 gary.harris@state.nm.us http://www.nmstatelibrary.org "You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." -- Buckminster Fuller -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Nicole Engard Sent: Wednesday, May 11, 2011 11:38 AM To: Chris Cormack Cc: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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
This is my vote! I know it takes more work and more time for features to be approved, but I'm for a more stable, tested Koha. That said, I am most certainly not for option #4. Chris has done amazing things for Koha, for open source, and for me personally. Without your efforts Chris I wouldn't be a Koha community member today and would have never thought to help get the manual off the ground. I agree that you do look out for the best interests of Koha and I think that a more stable Koha is in the best interests of the software and the community. Nicole _______________________________________________ Koha-devel mailing list Koha-devel@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/
On May 11, 2011, at 10:01 AM, Chris Cormack wrote:
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
We feel that the "well-defined" workflow has been missing before the start of 3.4 and would be very upset if this workflow was changed (untested patches--). Maybe it's just taking everyone time to adjust to this workflow. Honestly this has been much better and clearer for our organization to both track the process and for our organization to get our work into Koha. The way that I look at it - it's the responsibility of the developer (in my case - the company) to get the QA/sign-off necessary and we also add that amount of work into our workflows and contracts. Our job is not done until the code is tested and in - If that's the contract we sign (releasing it - is not enough in my opinion). This option is very clear for both the developer and the QA/RM roles. Yes it's more work for the developer - but it's a necessary for the stable project. I'm glad that someone is sticking to the rules and not bending. I/we vote for option #1. -Brendan ByWater Solutions
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@lists.koha-community.org im Auftrag von Chris Cormack Gesendet: Mi 11.05.2011 19:01 An: koha-devel@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@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/
All, On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
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.
I certainly think so! Also, we've had releases *every month*! 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
I think it would be very unfortunate to lose you as RM. Under your leadership, 3.4 rocked, and 3.6 promises to be even better. I vote for choice 1, unless someone has a concrete suggestion on how to refine the workflow for choice 2 (though, I will say, to me personally the current workflow seems to make a lot of sense), at which point I'd be interested in listening. Regards, Jared Camins-Esakov -- Jared Camins-Esakov Freelance bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Okay, Jared, you touched a spot that I've got to point at, teammate. On 5/11/2011 2:01 PM, Jared Camins-Esakov wrote:
has a concrete suggestion
Here, precisely, is what's needed, rather that someone kvetching about a process that they don't approve of. If someone is unhappy with the current process--as sane as it seems to me and (apparently) many others--then that's fine; no one requires that you be happy with it. But bring a concrete alternative that isn't "go back, go back!".... The community has proven that they're willing to hear new ideas, over and over again, and no one's gonna throw you over the wall without listening first. There's no such thing as an easy way to do what we're trying to do--it's too big, and too complex, for "easy." Any process will of necessity have a bottleneck or two, no avoiding it. But the current process, as demonstrated by the 3.4 release, *works,* and it's only going to get better. If someone has an alternative that they think might work better, bring it. Upsetting Chris and others is *not* a process that will work better. -- *D Ruth Bavousett* Lead Migration Specialist ByWater Solutions Support and Consulting for Open Source Software VISIT US AT ALA: BOOTH 732 Headquarters: Santa Barbara, CA Office: Washington, DC Phone/Fax (888)900-8944 http://bywatersolutions.com ruth@bywatersolutions.com
Hi, On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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
+1
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.
This would be a huge step backwards. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
On Wed, May 11, 2011 at 2:24 PM, Galen Charlton <gmcharlt@gmail.com> wrote:
Hi,
On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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
+1
+1 as well.
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.
This would be a huge step backwards.
It would indeed. The 3.4-plus workflow and release schedules have been changes necessary to the substructure of Koha in order for it to support the rapidly expanding superstructure. Reverse them, and the entire thing is in danger of collapsing. Anyone who expects their work to be pushed untested is out of line imho. Kudos to Chris C for a job well done and sticking to the rules. Kind Regards, Chris
Another vote for keeping the current workflow. Chris has done a fantastic job as RM, nothing else needs to be said. Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org ) On Wed, May 11, 2011 at 1:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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@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/
Chris, You are doing an excellent job as release manager!! Looking at the list, you are certainly not out of step with the community. Please continue to do so, perhaps even with some more sleep ;) Referring to a mail I posted yesterday, I would go for something between option 1 and option 2. I do not favor pushing without testing. So please excuse my repeating it here: Could we also assign people to signing off patches by bug category, just as we have some (old?) defaults for bug assignment? These persons could signoff themselves or take the lead in asking others to signoff a patch. (Or even thank the new developers for sending a patch, just as in the simplicty document.) I would be willing to have one or two categories.. If this approach of having two assignments is not practical, we could reevaluate the current assignments and ask everyone on that list to take the signoff responsibility too (including delegating signoffs and advertizing bugs just like Paul's hacking corner mails). It would add to the job of "bug wrangler" and hopefully make it easier for QA manager and RM.. Any comments on that approach?? Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Chris Cormack Verzonden: woensdag 11 mei 2011 19:02 Aan: koha-devel@lists.koha-community.org Onderwerp: [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@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/
So please excuse my repeating it here: Could we also assign people to signing off patches by bug category, just as we have some (old?) defaults for bug assignment?
I don't think we should set up a new "rule" to follow and old one that doesn't much work. Having default bug assignments doesn't really work very well because hardly any bug category has few enough bugs for any one person to be responsible for them. How would this be any different with assignments for signing off on bugs? Particularly when the same pool of people who are getting the default assignments will be splitting up the default signoffs. Perhaps we need to get creative about soliciting signoffs. "I'll test yours if you test mine?" -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
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
On 12/05/11 20:15, Paul Poulain wrote: (snip)
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 ;-)]
I am not a developer. I enter this discussion in a spirit of the greatest respect for Chris and for Paul, two giants of the Koha project. I am aware that in all likelihood, my understanding of the issues here is shallow. I desperately want to preserve the unity of the community. I think the work flow is sound and that Chris is to be congratulated for enforcing it, to ensure the quality of the Koha code. I also think Biblibre's problem is real and deserves recognition. There are times (or features) where the community lacks the resources to achieve sign-off. A compromise is needed. My thinking is influenced by the knowledge that the patches Biblibre seeks to incorporate have been tested and accepted by customers and are operating features in regular use. The main issue (I guess) is the passage of time since they were re-based against Master. (Forgive me if that is not technically correct - I think its close in principal?) How about this approach: - we designate a very small number of companies with the capacity and track record of major feature integration, as being authorised to short cut community QA before integrating major features (only); - minor features and bug fixes remain subject to the existing work flow; - I'm thinking ByWater, Biblibre and Catalyst at this stage - others can argue their own case; - such features must be integrated at least two months before a scheduled release, and assistance provided to community members to perform testing; - if significant problems are detected that are not rectified n weeks (2?) before release date, the feature will be withdrawn. I'm sorry if this is naive. I hope it may help the discussion along. Bob Birchall
On Thu, May 12, 2011 at 8:41 AM, Bob Birchall <bob@calyx.net.au> wrote:
How about this approach: - we designate a very small number of companies with the capacity and track record of major feature integration, as being authorised to short cut community QA before integrating major features (only);
- minor features and bug fixes remain subject to the existing work flow;
Minor features and bug fixes are less likely to break something than major features. It is precisely *because* some of the features pending signoff are so large and broadly-scoped that it is difficult to properly test them. Part of becoming more "agile," if we must use that term, is to learn to keep our contributions manageable and feature-specific. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Thu, May 12, 2011 at 8:41 AM, Bob Birchall <bob@calyx.net.au> wrote:
How about this approach: - we designate a very small number of companies with the capacity and track record of major feature integration, as being authorised to short cut community QA before integrating major features (only); - minor features and bug fixes remain subject to the existing work flow; - I'm thinking ByWater, Biblibre and Catalyst at this stage - others can argue their own case; - such features must be integrated at least two months before a scheduled release, and assistance provided to community members to perform testing; - if significant problems are detected that are not rectified n weeks (2?) before release date, the feature will be withdrawn.
I don't like this (even if ByWater is included above). Who decides who's special? Why do we need someone to be 'special'? The rules should apply to everyone regardless of who they are. That's why it was so much fun for me to mark one of Chris's patches as failing QA :) ... using your model his patch would have made it in to Koha and wouldn't have done what it expected. Not to pick on Chris, but the point is that no one should be exempt and no one is flawless. On Thu, May 12, 2011 at 8:51 AM, Owen Leonard <oleonard@myacpl.org> wrote:
Part of becoming more "agile," if we must use that term, is to learn to keep our contributions manageable and feature-specific.
I agree with Owen. We need to make things manageable. Nicole
My thinking is influenced by the knowledge that the patches Biblibre seeks to incorporate have been tested and accepted by customers and are operating features in regular use. The main issue (I guess) is the passage of time since they were re-based against Master. (Forgive me if that is not technically correct - I think its close in principal?) You're technically correct. How about this approach: - we designate a very small number of companies with the capacity and track record of major feature integration, as being authorised to short cut community QA before integrating major features (only); Sounds a good idea/necessity according to me. Of course, features should not be merged "from nowhere" and clearly/proudly announced. Any feature
- minor features and bug fixes remain subject to the existing work flow;
- I'm thinking ByWater, Biblibre and Catalyst at this stage - others can argue their own case; sounds a good list ( except it's BibLibre, not Biblibre :D ) - such features must be integrated at least two months before a scheduled release, and assistance provided to community members to perform testing; mmm... I feel 2 months may be too close to the release for major changes. I think 4 months is better. (see my proposal tomorrow: 2 months "quick features", 2 months "strong QA features" and 2 months "feature freeze", roughly. - if significant problems are detected that are not rectified n weeks (2?) before release date, the feature will be withdrawn. Yep. But I can promize that BibLibre will rectify any problems immediatly, as it will be the version we will release to our customers !
Le 12/05/2011 14:41, Bob Birchall a écrit : that sounds a problem to the community should not be merged either (for example, BibLibre wouldn't merge his solR stuff without agreement from a functionnal point of view. I don't mean a sign-off, because I'm "sure" no-one would be able tosign-off. I see something very interesting with this option : we could have a "sandbox" where librarians/anyone could test a freshly merged feature. I'm sure that would increase the number of tester & bug reporters. the question being "what is minor" ? but maybe the monthly meeting can be the place to discuss all the features and decide which is "minor" and which is not ;-) that's our business responsability !!!
I'm sorry if this is naive. I hope it may help the discussion along. This is not naive, this is a very good proposition to be agile again !
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi to all, Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch Attention the idea is A-developers CAN auto sign_off, and the the bugzilla need to isert where the test the feature (user that regulary use it, bug on public git, etc.). More power = more resposability. If an A-developer doesn't sign_off its patch in one day, it is a patch that needs sign_off from an other person. A B-developer need to find a person to test his code, and could be also a user, if he prepare a test enviroment. In fact I'm planning to do exatly in this way. I have 1-2 user with good IT skill, I will open to them a demo site with master + my patch and they read bugzilla, do tests and after they sign_off. Bye Zeno -- Dott. Zeno Tajoli tajoliAT_SPAM_no_prendiATcilea.it fax +39 02 2135520 CILEA - Consorzio Interuniversitario http://www.cilea.it/disclaimer
On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli <tajoli@cilea.it> wrote:
Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch
This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Le 12/05/2011 15:40, Owen Leonard a écrit :
On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli <tajoli@cilea.it> wrote:
Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved. Strongly disagreeing: many projects uses that kind of organisation. And as a newbie i would be happy to know i'm in a special state that ensure that what I'm doing will be reviewed by someone experienced !
Let me say also that getting more ppl involved does also mean not loosing your existing contributors (which is what will arrive with BibLibre contributions if we can't find an agreement that is OK for everybody) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
As a) a newbie myself, b) someone scared to death of the development process but still wanting to be involved, and c) one who wants a lot of things developed that will benefit the Koha community as a whole but specifically help Koha to work for archival institutions, I'm going to go against what seems to be the position of my support company (ByWater Solutions) and side with Paul on this one. I'd be more willing to contribute to if I were "in a special state that ensures that what I'm doing will be reviewed by someone experienced !" The way Paul describes, I think, makes everyone "special" - which we all are - just in different ways. IMHO, it's not as much a "hierarchy" (I'm better than you are and therefore look down on you) situation, as a fact of life. I don't know what the compromise is, but I think there is bound to be one. Sorry, if I overstepped by voicing my opinion, since I'm not sure I even get a vote. Linda On 5/12/2011 9:03 AM, Paul Poulain wrote:
Le 12/05/2011 15:40, Owen Leonard a écrit :
On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli<tajoli@cilea.it> wrote:
Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved. Strongly disagreeing: many projects uses that kind of organisation. And as a newbie i would be happy to know i'm in a special state that ensure that what I'm doing will be reviewed by someone experienced !
Let me say also that getting more ppl involved does also mean not loosing your existing contributors (which is what will arrive with BibLibre contributions if we can't find an agreement that is OK for everybody)
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824
On Thu, May 12, 2011 at 10:25 AM, Linda Culberson <lculber@mdah.state.ms.us> wrote:
I'd be more willing to contribute to if I were "in a special state that ensures that what I'm doing will be reviewed by someone experienced !"
That's the way the process works now, only *everyone* must get their work reviewed. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Le 12/05/2011 16:25, Linda Culberson a écrit :
Sorry, if I overstepped by voicing my opinion, since I'm not sure I even get a vote. Nope, you haven't overstepped anything. We are specially listening to newbies opinion. Old timers like chris & me may have experience, but newbies may have ideas. That's one of the reason why, after being RM for 2 versions I've been happy to see someone else, with a lot of ideas, being a candidate ( as chris said: it was not the best decision i've "voted", but it's easy to say that now we know what happened -see http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html if you don't know- )
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Maybe I'm not getting it here, BUT..have we forgotten how long it takes PROPRIETARY VENDORS to develop and debug their code? Maybe it's just me, but I'm amazed at how fast these releases are getting out there. (3.0, 3.2, 3.4...3.6...already?) It will be out soon, I'm sure. Also, and I know it's a hassle, but what's stopping you from writing your own code, integrating it into your instance of Koha, and using it while waiting for code to be tested and accepted into community? You're getting the benefits of your own written, or sponsored, code while having the peace of mind of getting the QA testing from the community. Again, maybe it's me, but am I missing something here? Have we become that impatient and spoiled that we want our pellet now, and let the process be damned? Scott Kushner Information Systems Librarian Middletown Public Library -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of Paul Poulain Sent: Thursday, May 12, 2011 10:32 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 16:25, Linda Culberson a écrit :
Sorry, if I overstepped by voicing my opinion, since I'm not sure I even get a vote. Nope, you haven't overstepped anything. We are specially listening to newbies opinion. Old timers like chris & me may have experience, but newbies may have ideas. That's one of the reason why, after being RM for 2 versions I've been happy to see someone else, with a lot of ideas, being a candidate ( as chris said: it was not the best decision i've "voted", but it's easy to say that now we know what happened -see http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html if you don't know- )
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ Koha-devel mailing list Koha-devel@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/
Le 12/05/2011 16:49, Scott Kushner a écrit :
Maybe I'm not getting it here, BUT..have we forgotten how long it takes PROPRIETARY VENDORS to develop and debug their code?
Maybe it's just me, but I'm amazed at how fast these releases are getting out there. (3.0, 3.2, 3.4...3.6...already?) It will be out soon, I'm sure. Also, and I know it's a hassle, but what's stopping you from writing your own code, integrating it into your instance of Koha, and using it while waiting for code to be tested and accepted into community? You're getting the benefits of your own written, or sponsored, code while having the peace of mind of getting the QA testing from the community.
Again, maybe it's me, but am I missing something here? Have we become that impatient and spoiled that we want our pellet now, and let the process be damned?
Scott Kushner Information Systems Librarian Middletown Public Library
Scott, The problem we have in BibLibre is that we developped things for 3.4 as 3.2 was not out. And that some other features have been pushed that broke our code. Therefore we had to re engineer that code 4 times. And that at some point, we are quite getting upset to see that still, that code is not going to get seriously considered because it scares ppl away. Having waited for over 2 years is quite a long time. And we would like to get things validated. More and more libraries are working now with that code... because they ask for Koha AND those features... Kyle Hall may have the same issues, but his features are more external modules, so he may be ok with that and handle that ok. For us it has not been a problem not to see that in 3.2 . It was announced in RFCs for 3.4, but it was developped and delivered before 3.2 was out. And contains both new features and bug fixes... (Because, believe it or not, as we developped, we discovered existing bugs...) And we have our french bugtracker. But each and every bug we declared in our bugtracker was not translated and updated in bugzilla because we worked hard to get things done. And the wonderful job done by the community (which I donot negate) is making our lives a nightmare rebasing and redoing things. So that we are wondering whether we could continue working and proposing features, if we cannot make them in 2 years after they are delivered and tested. But it is not only a BibLibre problem. I think, many libraries are working with a Koha fork (little or big, a fork is a fork, would it be just an xslt change) that is fitting their needs. Our problem is that we donot want this to happen for our libraries and our code, and we care. And that we have vainly struggled to make them in in many ways. So that at some point, financially, technically, and strategically some concerns have to be discussed. What will happen when we are more than 5 very active companies if some big features are lost in the wild and re processed by another firm or will have to be re engineered over and over again because there is no planning, no developing group, no vision, no common goal. It already happened with fine in days. Two companies did work on that feature, we and xercode, and still, that feature is not in Koha. And it is just an exemple. Friendly -- Henri-Damien LAURENT
On 13 May 2011 02:25, "Linda Culberson" <lculber@mdah.state.ms.us> wrote:
As a) a newbie myself, b) someone scared to death of the development
process but still wanting to be involved, and c) one who wants a lot of things developed that will benefit the Koha community as a whole but specifically help Koha to work for archival institutions, I'm going to go against what seems to be the position of my support company (ByWater Solutions) and side with Paul on this one. I'd be more willing to contribute to if I were "in a special state that ensures that what I'm doing will be reviewed by someone experienced !" The way Paul describes, I think, makes everyone "special" - which we all are - just in different ways. IMHO, it's not as much a "hierarchy" (I'm better than you are and therefore look down on you) situation, as a fact of life. I don't know what the compromise is, but I think there is bound to be one.
Sorry, if I overstepped by voicing my opinion, since I'm not sure I even
get a vote.
Linda
Everyone gets a vote. And as Owen said you aren't actually siding against ByWater (im not sure there even are sides), all new patches get oversight, in fact ALL patches get oversight. Thats the current process. What we are discussing, and there seems to be a good discussion on IRC about how to make it easier for people to provide oversight. I am very heartened the discussion is moving in that direction, because I think that is where we win. Make the sign off easier, not remove the need for sign off Chris
On 5/12/2011 9:03 AM, Paul Poulain wrote:
Le 12/05/2011 15:40, Owen Leonard a écrit :
On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli<tajoli@cilea.it> wrote:
Reading the Paul and Chris mails, I think we can give different level
to
developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch
This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved.
Strongly disagreeing: many projects uses that kind of organisation. And as a newbie i would be happy to know i'm in a special state that ensure that what I'm doing will be reviewed by someone experienced !
Let me say also that getting more ppl involved does also mean not loosing your existing contributors (which is what will arrive with BibLibre contributions if we can't find an agreement that is OK for everybody)
-- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives & History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Fax: 601/576-6824
_______________________________________________ Koha-devel mailing list Koha-devel@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/
Le 12/05/2011 16:45, Chris Cormack a écrit :
I am very heartened the discussion is moving in that direction, because I think that is where we win. Make the sign off easier, not remove the need for sign off I'm not requesting to remove the sign-off. I'm saying our code reaches bugzilla already "signed-off" at least twice (project manager and customer/library), so, yes, the "A-dev" idea of zeno or the "shortcut" idea of Bob is a good one. And I know that "with great power comes great responsibility". I'm very disheartened that the discussion just moves to "make signoff easier".
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, May 12, 2011 at 10:56 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
I'm not requesting to remove the sign-off. I'm saying our code reaches bugzilla already "signed-off" at least twice (project manager and customer/library),
Paul, I'm very confused, if your stuff is "signed off" why not just stick the -s in the format-patch command and be done with it? Show everyone that it's signed off and it will go to QA and not have to wait for the rest of us to sign off again. If your patches are signed off, just show that in the patch itself. Nicole
I'm not requesting to remove the sign-off. I'm saying our code reaches bugzilla already "signed-off" at least twice (project manager and customer/library), Paul, Nicole, I'm very confused, if your stuff is "signed off" why not just stick
On Thu, May 12, 2011 at 10:56 AM, Paul Poulain <paul.poulain@biblibre.com> wrote: the -s in the format-patch command and be done with it? Show everyone that it's signed off and it will go to QA and not have to wait for the rest of us to sign off again. It's because we can't ask the customer or the project manager (a
Le 12/05/2011 16:58, Nicole Engard a écrit : librarian) to git format-patch -s ! They are validating the feature by testing, and say "OK, it works". So no "signed-off by XXX" on the patch. Do you think/mean we should just create all our patches with status "signed-off" ? It's a kind of "shortcut" / "A-developer" isn't it ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, May 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
It's because we can't ask the customer or the project manager (a librarian) to git format-patch -s !
As a librarian that's just you not giving them enough credit. I agree you don't ask the customer (unless the customer wants to do it) but you can ask and train your project manager. We have customers test our patches and then they're passed on to one of us for a sign off. It's simple, it takes 1 minute more time and it means our patches make it to QA. I feel like this is all being made much harder than it really is. Patches must be signed off, we have a policy in place for that, we cannot assume that patches have been signed off based on who submits them because then we start making exceptions all over the place. Nicole
On 13 May 2011 03:10, Nicole Engard <nengard@gmail.com> wrote:
On Thu, May 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
It's because we can't ask the customer or the project manager (a librarian) to git format-patch -s !
As a librarian that's just you not giving them enough credit. I agree you don't ask the customer (unless the customer wants to do it) but you can ask and train your project manager. We have customers test our patches and then they're passed on to one of us for a sign off. It's simple, it takes 1 minute more time and it means our patches make it to QA.
I feel like this is all being made much harder than it really is. Patches must be signed off, we have a policy in place for that, we cannot assume that patches have been signed off based on who submits them because then we start making exceptions all over the place.
Another option is to set the bug to Signed Off And note in the notes, who signed it off "Billy Bob Library signed this off on the 12/5/2011, tested also by Janey Joe Library. Developed internally by sue and james, and signed off internally by kathy" Also the signed off part of a patch is not anything super special you don't have to do it with -s If Lyon has signed off a patch (tested it, approved it works and breaks nothing else). You can add Signed-off-by: Lyon University To the patch just before the ---, and it will show as signed off. git is cool like that Chris
Le 12/05/2011 17:10, Nicole Engard a écrit :
As a librarian that's just you not giving them enough credit. I agree you don't ask the customer (unless the customer wants to do it) but you can ask and train your project manager. We have customers test our patches and then they're passed on to one of us for a sign off. It's simple, it takes 1 minute more time and it means our patches make it to QA. Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say)
Paul wrote:
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] -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, May 12, 2011 at 11:30 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say)
I'm saying that you're not giving your librarian/project manager enough credit. I'm saying that as a trainer I hate it when people say that a librarian can't do something cause they're a librarian. Nicole
On Thu, May 12, 2011 at 11:30 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say)
I'm saying that you're not giving your librarian/project manager enough credit. I'm saying that as a trainer I hate it when people say that a librarian can't do something cause they're a librarian.
Nicole Well,
Le 12/05/2011 17:34, Nicole Engard a écrit : translations, trainings, project management, interface with libraries in the global design are already HUGE tasks. It is not a matter of 'credit', it is a matter of time. I donot want to ask them to spend time on what looks geeky stuff to them. They have a role, with enough responsablility and are devoted enough not to add them a task, taking the git code onto their laptop, and adding sign-off on the patch. But ok it is not out of reach to imagine that future patches will have sign offs when they are submitted, even fancy ones like Limoges and Saint Etienne... Even though, sign off changes the commit id. With a merge workflow, it breaks the whole thing. But OK the community despises merge workflow. We could send patches onlist. Fair enough... For the future, if we can continue to contribute. But we have some old patches there. And those patches are touching serious parts (circulation and members). And those patches are important both for us and for some of our libraries. And rebasing, having to reengineer them over and over makes that more and more risky. Adding a REBASE tag to the patch and resending all the patches that need rebasing any time they need rebasing would quite spam the list I guess with the 150 patches waiting sign-off (I am not speaking of BibLibre particularly there but xss patch for instance.). Friendly -- Henri-Damien LAURENT
On Thu, May 12, 2011 at 11:30 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So you've inclined to vote 2 to my previous question? (Or do I go too far, and it's not what you want to say)
I'm saying that you're not giving your librarian/project manager enough credit. I'm saying that as a trainer I hate it when people say that a librarian can't do something cause they're a librarian.
Nicole Well,
Greetings all, Reading this thread I think the core issue is this. Can a *big* enhancement that has been developed by one company be signed off by that company as well. Currently the work flow suggests that anything more than minor bugs should not be signed off by someone in the same company. However, if within the company developer A has done the work, developer B has tested it and signed off internally, and it is in use at a library that the company supports and is running without issue, then is that enough to allow it to be pushed to the master branch of that release? I think it is. As a minor developer (I submitted an enhancement that the librarian where I work wanted implemented) I can say that I welcomed the help of the community, including the feedback during the process as well as some revisions to my code to make it cleaner. The process was a little daunting for a total newbie but I got a lot of help and was happy to have the requirement in place that someone else sign off on my changes. But I am the IT support person for a small non-profit that includes an academic library. This is a small part of my job, not my primary business. I don't mind having different rules for me than for those that are providing the primary development and support for Koha. So perhaps a simple change fixes this, allowing an internal sign off for any bug/enhancement, not just for the "minor" ones. Then push to master so no one has to rebase constantly. Or am I missing something crucial? Regards, Doug Dearden Director, IT School for Advanced Research (505)954-7220 sarweb.org -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of LAURENT Henri-Damien Sent: Thursday, May 12, 2011 10:51 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 17:34, Nicole Engard a écrit : translations, trainings, project management, interface with libraries in the global design are already HUGE tasks. It is not a matter of 'credit', it is a matter of time. I donot want to ask them to spend time on what looks geeky stuff to them. They have a role, with enough responsablility and are devoted enough not to add them a task, taking the git code onto their laptop, and adding sign-off on the patch. But ok it is not out of reach to imagine that future patches will have sign offs when they are submitted, even fancy ones like Limoges and Saint Etienne... Even though, sign off changes the commit id. With a merge workflow, it breaks the whole thing. But OK the community despises merge workflow. We could send patches onlist. Fair enough... For the future, if we can continue to contribute. But we have some old patches there. And those patches are touching serious parts (circulation and members). And those patches are important both for us and for some of our libraries. And rebasing, having to reengineer them over and over makes that more and more risky. Adding a REBASE tag to the patch and resending all the patches that need rebasing any time they need rebasing would quite spam the list I guess with the 150 patches waiting sign-off (I am not speaking of BibLibre particularly there but xss patch for instance.). Friendly -- Henri-Damien LAURENT _______________________________________________ Koha-devel mailing list Koha-devel@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/
Hi, On Thu, May 12, 2011 at 1:03 PM, Doug Dearden <dearden@sarsf.org> wrote:
Reading this thread I think the core issue is this. Can a *big* enhancement that has been developed by one company be signed off by that company as well. Currently the work flow suggests that anything more than minor bugs should not be signed off by someone in the same company. However, if within the company developer A has done the work, developer B has tested it and signed off internally, and it is in use at a library that the company supports and is running without issue, then is that enough to allow it to be pushed to the master branch of that release? I think it is.
I disagree. Successful use in a library is evidence that the feature meets that particular library's needs. It is not sufficient evidence that the implementation of the feature is good and does not interfere with other libraries' use of Koha. It is also not sufficient evidence that the work has been constructed, documented or explained enough for other users or developers to understand, build on, or enhance the feature. The larger the feature, the more independent review matters. I would consider one developer working for a given employer signing off on the work of another employee to be the bare minimum of acceptable process, and for small patches, that's often enough. For larger features, particularly ones that involve architectural changes, I will make a flat out assertion: sign-offs within the same employer doesn't cut it. It has to work well enough and be explained well enough that, at minimum, the QA manager and the release manager can understand it and test. One key thing is that larger features *must* be developed incrementally, in the open, and with as much discussion as possible. Regards, Galen -- Galen Charlton gmcharlt@gmail.com
Le 12/05/2011 19:17, Galen Charlton a écrit :
Hi,
On Thu, May 12, 2011 at 1:03 PM, Doug Dearden <dearden@sarsf.org> wrote:
Reading this thread I think the core issue is this. Can a *big* enhancement that has been developed by one company be signed off by that company as well. Currently the work flow suggests that anything more than minor bugs should not be signed off by someone in the same company. However, if within the company developer A has done the work, developer B has tested it and signed off internally, and it is in use at a library that the company supports and is running without issue, then is that enough to allow it to be pushed to the master branch of that release? I think it is.
I disagree. Successful use in a library is evidence that the feature meets that particular library's needs. It is not sufficient evidence that the implementation of the feature is good and does not interfere with other libraries' use of Koha. It is also not sufficient evidence that the work has been constructed, documented or explained enough for other users or developers to understand, build on, or enhance the feature.
The larger the feature, the more independent review matters. I would consider one developer working for a given employer signing off on the work of another employee to be the bare minimum of acceptable process, and for small patches, that's often enough. For larger features, particularly ones that involve architectural changes, I will make a flat out assertion: sign-offs within the same employer doesn't cut it. It has to work well enough and be explained well enough that, at minimum, the QA manager and the release manager can understand it and test.
One key thing is that larger features *must* be developed incrementally, in the open, and with as much discussion as possible. Well on that regard, we have never been developped in the background.
It has been announced with RFCs, it has been added with bugs. Discussion, with whom, when, where ? At least we never avoided that. For many aspects, we have tried to provoke discussion before. The fact is that we cannot always beg for comments externally and wait for ppl to realise that we are working. We also have due dates. Every one has. If ppl are not willing to discuss the moment we need to discuss, when things are done, if there is discussion, then ppl may also share the work and not just burry others with idle criticisms. And about documentation and explanation, well, it seems quite strange to say so when you look at the current status of most of the current code and all the oddities in behaviour or coding standards we have seen. I reckon we also took a part in that. And maybe you will say that our contributions are so terrible we should not even dare. But still, the remove items branch was quite a common work... even if it took much time. And I think it was valuable, although you missed one of the important point I tried to assign : display. (it was done maybe quite awkwardly for want of time, but done) And then again, documentation is nice, but also needs to be maintained and detailed. And something that may seems obvious to one person can not be for someone else... For what it is worth, most of the time, we have to dive into the code and cannot rely on the documented behaviour. -- Henri-Damien LAURENT
Hi Paul, On Thu, May 12, 2011 at 11:07 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Do you think/mean we should just create all our patches with status "signed-off" ? It's a kind of "shortcut" / "A-developer" isn't it ?
We are currently accepting patches into QA which are signed off by employees of the same company as the author of the patch. So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in order to get their patches into QA? Perhaps if the issue is moving patches representing larger/more complicated features through QA, the submitter could provide references to installations/clients currently running the feature(s). The QA manager could then contact the supplied reference to verify QA and push the patch on up the chain. Kind Regards, Chris
Le 12/05/2011 17:26, Chris Nighswonger a écrit :
We are currently accepting patches into QA which are signed off by employees of the same company as the author of the patch.
So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in order to get their patches into QA? I'm not only speaking of patches fixing a bug, but also of large updates adding a feature. Chris has said he wouldn't accept such a patch/branch self-signed. Perhaps if the issue is moving patches representing larger/more complicated features through QA, the submitter could provide references to installations/clients currently running the feature(s). The QA manager could then contact the supplied reference to verify QA and push the patch on up the chain. mmm... That would be fun to see one of our -French speaking- library answering a mail in English ;-) I don't think it's a possible way to go.
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On 13 May 2011 03:42, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 12/05/2011 17:26, Chris Nighswonger a écrit :
We are currently accepting patches into QA which are signed off by employees of the same company as the author of the patch.
So I'm a bit confused as to why Biblibre cannot adopt a similar procedure in order to get their patches into QA? I'm not only speaking of patches fixing a bug, but also of large updates adding a feature. Chris has said he wouldn't accept such a patch/branch self-signed.
That's exactly right, but luckily for 3.6 we have another step, the QA manager. So self signed would be enough, (preferably one external one as well) to get it to the QA manager. If it then passes QA, its on to me as RM.
Perhaps if the issue is moving patches representing larger/more complicated features through QA, the submitter could provide references to installations/clients currently running the feature(s). The QA manager could then contact the supplied reference to verify QA and push the patch on up the chain. mmm... That would be fun to see one of our -French speaking- library answering a mail in English ;-) I don't think it's a possible way to go.
Well I still think its important that it is noted on the bug or on the patch, who has claimed that it works. They should get credit for testing at least Chris
On Thu, May 12, 2011 at 3:03 PM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
Le 12/05/2011 17:26, Chris Nighswonger a écrit :
We are currently accepting patches into QA which are signed off by employees of the same company as the author of the patch.
So I'm a bit confused as to why Biblibre cannot adopt a similar
On 13 May 2011 03:42, Paul Poulain <paul.poulain@biblibre.com> wrote: procedure in
order to get their patches into QA? I'm not only speaking of patches fixing a bug, but also of large updates adding a feature. Chris has said he wouldn't accept such a patch/branch self-signed.
That's exactly right, but luckily for 3.6 we have another step, the QA manager. So self signed would be enough, (preferably one external one as well) to get it to the QA manager. If it then passes QA, its on to me as RM.
Following up on this, for work developed and internally signed off by ByWater Solutions, I'm going to mark smaller things that pass QA as such. But, for larger developments, I'm going to need someone's eyes from outside my company to check the code and give a signoff. If my judgement of what's "small" and what's "large" ever seems suspect to anyone, PLEASE call shenanigans on me, and I'll address it. -Ian -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On Thu, May 12, 2011 at 11:42 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 12/05/2011 17:26, Chris Nighswonger a écrit :
Perhaps if the issue is moving patches representing larger/more complicated features through QA, the submitter could provide references to installations/clients currently running the feature(s). The QA manager could then contact the supplied reference to verify QA and push the patch on up the chain. mmm... That would be fun to see one of our -French speaking- library answering a mail in English ;-) I don't think it's a possible way to go.
Language will always be a "problem" with any international project. So this really is a non-argument imho. Providing a reference for QA on large feature sets would be valuable and well worth the effort it would take to get over the translation hurtle. I'm sure that just the time consumed in pursuing this very thread would have been sufficient to have accomplished a confirmation of QA with a non-English speaking reference including time taken to obtain an accurate translation. I work in an environment every day of the year with folks from *multiple* countries who are non-native English speakers (some only speak a very few words of English) and this is by no means a show-stopper for our business. Difficult? Yes. Impossible? No. So I respectfully disagree: This is a very possible way to go. Kind Regards, Chris
Le 12/05/2011 16:58, Nicole Engard a écrit :
On Thu, May 12, 2011 at 10:56 AM, Paul Poulain <paul.poulain@biblibre.com> wrote:
I'm not requesting to remove the sign-off. I'm saying our code reaches bugzilla already "signed-off" at least twice (project manager and customer/library),
Paul,
I'm very confused, if your stuff is "signed off" why not just stick the -s in the format-patch command and be done with it? Show everyone that it's signed off and it will go to QA and not have to wait for the rest of us to sign off again.
If your patches are signed off, just show that in the patch itself.
Nicole
Nicole We have a merge workflow rather than a sign off on individual patches. That way, features can be tested and integrated much more smoothly. Unfortunately, signing off changes the commit id. And it requires some more actions, that our project manager will not be able and not be willing to add in their process. So that, Paul is speaking of a user sign off but not a git sign-off. That 'git sign-off' all mighty process looks strange to me. It supposes a feature touches only some little parts of Koha, and quite often, it is not the case or makes very little changes. The problem is that those not signed-off patches were rebased from our code, then re-process by Paul and then by Chris, and we kept from signing off on those because Chris wanted some other company to sign them... And Chris kept from having them signed-off by one of his catalyst teammate because he wanted some one else to have a look at them. Problem is that then... noone tests them sign off on them. Your workflow doesnot fit merge workflow. How would we cope with a git-pullrequest ? would we ask for a signoff in every single patch ? would we just test the branch, see how it works and do the merge and if that does not merge straight forward, ask for rebase ? And when you develop things once, twice and then 4 times, one ends up quite nervous at getting things behind. We participated and play our part in sign off, and development process. Some features were not contributed though talked about for some time now. I think because of that kind of thing (thinking of EDI for instance, but maybe some other RFID process). It takes time to reprocess things and to adapt them when new features come into the way. Maybe libraries are ok with that. But in my opinion, when their features have not reached the trunk, they have wasted their money, and developers wasted their time. -- Henri-Damien LAURENT
On 12/05/11 14:40, Owen Leonard wrote:
On Thu, May 12, 2011 at 9:26 AM, Zeno Tajoli <tajoli@cilea.it> wrote:
Reading the Paul and Chris mails, I think we can give different level to developers. A-developers = you can auto-sign_off B-developer: a person of an other firm need to sign_off your patch
This discussion started in part because people were talking about how to get more people involved in Koha development. Setting up a hierarchy like this doesn't sound like a good way to get more people involved.
And its not absolute. Someone might confidently signoff fixes in one area but not have any confidence in signing off in another. Especially for new contributors the most useful thing isn't a sign off or rejection but the 'Great but have you considered the implications in x' kind of feedback. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
Chris Cormack <chris@bigballofwax.co.nz>
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. [...] Comments?
I think you're right. We're reworking ourselves to meet this policy (it will be good for the soul!) and should be back on board properly soon. I'd be disappointed to see the process change just as we really got it figured out! Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
On Wed, May 11, 2011 at 2:01 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
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.
First of all, Chris++ for the hard and good work he is doing every day. For a noob like me its leadership has been really inspiring and I'm comfortable with the current workflow which I think . As a 'small' (+30 libraries/koha deploys) contributor University, we've faced several times this problem Paul brought into discussion last year about BibLibre's difficulties to make community development roadmap/process fit their own's, and its' business model. Even if we are a small non-profit contributor we 'felt the same' [1]. I think it is not easy to avoid this problem: the tension between community established roadmap and the needs of a third party's business. Companies like BibLibre have made Koha the great piece of software it is now (the same goes for LibLime and other companies), so it is not just BibLibre's problem. Community and third parties roadmaps diverge easily. As Paul said, perhaps forking is the only solution for a business model if we don't find a proper solution. I'd like to see an approach that provided a proper semi-formal way to make strategic decisions on the future of the project, so that third parties can propose the community a "big feature" or a "big change", and the core developers can plan on how the integration will be done. If it fits the business model (i.e. secrecy is not a need for it), maybe even make external core devs have access to relevant information on the inside development process: develop on the open. I'd like to elaborate a bit more on the need for a strategic decision taking mechanism, but i've been busy with other project for which i'll fly to europe tomorrow. Maybe I get some more time to spend in koha in a few weeks. Thanks for all the hard work and good will put into this discussion. To+ [1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated.
On 13/05/11 15:05, Tomas Cohen Arazi wrote:
[1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated.
I think there is a problem with the process that rfc's stake out areas out areas of development then people wait around until the original proposer delivers putting things on hold. If it doesn't get delivered, delivered when expected or as expected then everyone loses out. Really until you show some code its all wishful thinking. ( I have a number of projects that will solve the world's ills but I've not released any code yet ). We should not be fearful of forking, the license we use could be seen as encouraging it but insisting that having forked you preserve the rights to the code you have just taken advantage of. With regular scheduled releases its easier to keep the fork in touch with the main branch which also makes it easier to fold it back in to the main line of development, because even if your fork has features that others may not want, you want all the good stuff that is in the main branch. As a community we are very good at implementing the middle range features (and don't belittle them they are what most of are users cherish in the system ). We're a bit less good at the big chunks of functionality but I'm sure thats fixable, (and Chris's successful shifting to TT for 3.4 shows big things can be done). We're also a bit behind the curve on the plumber like code maintenance tasks ( we are going to have use warnings in all scripts oneday, right?) that have less visible user impact but aid future development and avoid introducing bugs. Colin -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com
On Fri, May 13, 2011 at 12:37 PM, Colin Campbell <colin.campbell@ptfs-europe.com> wrote:
On 13/05/11 15:05, Tomas Cohen Arazi wrote:
[1] We even stopped developing some features our librarians asked for until we could understand and fit into the dev community and the process itself. WE DON'T WANT TO FORK. Several times we had the feeling we could have spent our money/time in a more feature-providing way, but where confident that we could make our voice into the dev community. Day suspension fines is a feature we proposed to develop ourselves with some core-developer guidance but only got this answer: "liblime has developed that, wait for them to merge their branch". We are currently working with a small, harmless fork we can maintain updated.
FTR: I'm in no way blaming LibLime in the example I provided. It should be read as self-criticism, probably because we feared having to fork (we cannot afford to do it, i'm the only dev maintaining all this stuff here) and wanted to do it "the right way" (from our perspective as a public university this means that if we invested some hours of human labour they should be applied to make koha better for everyone, specially spanish-speaking/latin-american users that, as Paul said, have interests in features NZ and US libraries don't even think about in their daily workflow ("who is interested in signing BZ6328 i just submitted ?": me)). I agree with the concepts you provided. Regards To+ (with a parenthesis nightmare)
participants (25)
-
Bob Birchall -
Brendan A. Gallagher -
Chris Cormack -
Chris Nighswonger -
Colin Campbell -
D Ruth Bavousett -
Doug Dearden -
Fischer, Katrin -
Galen Charlton -
Harris, Gary, DCA -
Ian Walls -
Indranil Das Gupta -
Jared Camins-Esakov -
Kyle Hall -
LAURENT Henri-Damien -
LAURENT Henri-Damien -
Linda Culberson -
Marcel de Rooy -
MJ Ray -
Nicole Engard -
Owen Leonard -
Paul Poulain -
Scott Kushner -
Tomas Cohen Arazi -
Zeno Tajoli