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