Le 22/02/2012 13:15, Marcel de Rooy a écrit : > Owen wrote: >> If someone want to write that, it's fine with me. It's a little over >> my head. That still leaves open the question of whether there is a >> course of action for getting this tested an approved which will be >> timely enough to make it worthwhile. > > That is an interesting question in general too. If we have community > consensus on some kind of change (before programming started) resulting in > "time-sensitive" patches, could we have some procedure to get them on a > priority lane through signoff and QA? > This would probably involve not only consensus on the changes but also the > promise for a quick signoff from other members. > Opening up a more general discussion? Good point Marcel,
and I think it can also be related to 2 others: * the database table naming thread = if we want to remove aq prefix, then should be remove all of them in one patch, of we do it step by step ? * bug 7113 = owen did a large job to standardize how we call the identifier of the shop where the library buys material from. It was sometimes id, sometimes supplierid, sometimes booksellerid, crapy... The patch has been pushed a few days ago, and it fixes everything, except that: - owen did not update/fix the database - there are a few places (in serials for example) un-standardized Should I have rejected the patch for this reason ? (I don't think so, it was a large patch, owen would have been tired to have to rebase it 10 times) The question can also be "rewriten" as : "for structural/deep changes", should we do small step by small step, or everything at once ? I feel/fear that everything at once will be very hard to manage. And small step by small step is much easier. For the "aq" or "not aq" thing for example, I'm not against having a "middle of the river" (frenchism ?) situation, with some tables having the "aq" prefix removed, and some not. For the CSS question, we could have, for a given period, the css available in 2 different places, so scripts updated would call the good version, and script still "to update" would call the old version. That would ensure the stability of Koha, the important thing being to have a consensus and clear volunteers. So my position here is "accept a patch if it goes in the right/consensus direction, even if it does not everything and if it does not break Koha" -- 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 [email protected] 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/
