[Koha-devel] Moving CSS and JavaScript out of translated paths

[Chris Cormack]

If there's one thing that everyone who has been release manager has learnt. It's that big patches that change a lot at once break more than they fix. Small incremental changes are almost always better.

If a patch moves the codebase forward towards a goal without causing bugs or regressions, accepting it at that point is a zillion times better than saying but can't it also do this. IMHO.

Chris
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Paul Poulain <paul.poulain at biblibre.com> wrote:

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
Koha-devel at 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20120223/540123d5/attachment.htm>