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