On 12 May 2011 00:19, Marcel de Rooy <M.de.Rooy@rijksmuseum.nl> wrote:
Liked that article! As relative new member of the community, I am wondering if the current signoff/passed_qa procedure really encourages new members to keep sending patches. It could happen easily now that a patch does not get any attention. What makes someone now select a patch for signoff? Coincidence, contacts, application feature? Unfortunately that has always been the case since we moved to the workflow of having patches. The new statuses and reports showing bugs waiting for sign off have I think made it less likely. For 3.4.0 for example there were over 1000 patches, from 66 different people in 6 months that made it in. So I think we are slowly improving all the time, and should strive to continue to do so.
Currently now the best way of getting a patch signed off, is asking someone to look at it. Jumping in the discussion: the workflow is great, in theory. But when no-one find time to sign-off a patch, it results in patches being lost in limbo. And when someone suddenly takes care, unfortunatly,
Le 11/05/2011 16:22, Chris Cormack a écrit : the patch does not apply anymore, so the patch writter has to rebase,... It not a good method to motivate ppl to contribute, obviously ! At the moment, we have 140 patches waiting for sign-off. Some including critical bugs. Just picking one of them: 5995 = It requires a CAS server to be tested, and I fear no-one has one. I can guarantee that the problem has been reported by a library using Koha. I can guarantee this is the patch we've applied, and the library has closed the bug on our internal platform. I can guarantee that this is exactly the patch we've made. And I can guarantee the library will never sign-off anything. So ... we're waiting for someone to sign-off this patch. And I feel we'll wait for a long time. Another example: 3652 (XSS vulnerabilities) I could add that many features we've submitted still have not made their way into Koha master, and it's not because of our efforts, it's because of this too strong workflow. They're too complex to apply/test/sign for someone not able to dedicate a full day to this task. But, once again, those features are working well for our customers, but they'll never sign-off anything ! Chris, I know we disagree here. But the workflow would be a good one if we had a long list of developers available, and we don't have. What's the solution ? I already have proposed, at the beginning of 3.4, to have pending features merged "immediatly", to let ppl (including librarians) time to do QA. You rejected this idea. I make it again : I think we should have a small time of, say, 2 months, where new features will be included easily. With a sandbox setup for anyone to test them (i'm definetly sure I could motivate french librarians to test. I'll never succeed to make them sign-off !). And during the 4 remaining months, 1- fix bugs on merged features (and even revert some if needed, like no feedback from the dev and big problems), 2- add features after a strong patch workflow. To summarize : T+0 - T+60 = any feature/patch that applies and is sent cleanly by a contributor that can promize he will take care of problems on the feature are merged T+60- T+150 = features/patches added only after a standard QA/signoff (i'm not sure i'm happy with a 1signoff+1QA barrier, I fear it's too high, but...) T+150 - T+180 = features & string freeze Without this, I think/feel that the "140" patches waiting for signoff will never be lowered. 15 persons worked for one full week during hackfest, and after 1 months, we're back to a number I consider as huge. PS : challenge: who is interested in signing BZ6328 i just submitted ? I feel no-one, as it's related to fines in days, and it seems it's something strange to US/NZ and many countries. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08