Moving CSS and JavaScript out of translated paths
I have done some work on Bug 4048, "Moving CSS and JS out of translated paths," but the work quickly becomes out of date because it touches so many files. I'm willing to keep working on it if others think it is still worthwhile, so I'd like to ask for opinions. The goal of the bug was to move common CSS and JavaScript files out of language-specific directories so that they are not duplicated. CSS and JavaScript files are not processed by the translation script, so there isn't much reason at the moment to keep them where they can be processed by it. The question is whether it might be a goal of some people to add translation of JavaScript files? The other question I have about revisiting my work on this bug is how I can submit a patch and expect it to be tested in a timely manner. Making a far-reaching change is inconvenient for everyone, I know. If we agree that the bug is worth fixing, how can we apply the fix in the least painful way? Thanks, Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 2012-02-22, at 4:09 AM, Owen Leonard wrote:
I have done some work on Bug 4048, "Moving CSS and JS out of translated paths," but the work quickly becomes out of date because it touches so many files. I'm willing to keep working on it if others think it is still worthwhile, so I'd like to ask for opinions.
The goal of the bug was to move common CSS and JavaScript files out of language-specific directories so that they are not duplicated. CSS and JavaScript files are not processed by the translation script, so there isn't much reason at the moment to keep them where they can be processed by it. The question is whether it might be a goal of some people to add translation of JavaScript files?
The other question I have about revisiting my work on this bug is how I can submit a patch and expect it to be tested in a timely manner. Making a far-reaching change is inconvenient for everyone, I know. If we agree that the bug is worth fixing, how can we apply the fix in the least painful way?
heya Owen, great work! gitorious wont let me look at your patch/diff via its gui, the web error is.... 'This Git object is too large to be displayed in the browser Consider cloning the repository locally and look at the object there' i have a suggestion (that may require too much work too?) perhaps a quick-dirty script that rewrites paths on the latest master repo, rather than a patch? might that work? (remember i cant see your patch via gitorious yet :) )
gitorious wont let me look at your patch/diff via its gui, the web error is....
The gitorious branch is out of date, but you could certainly get a sense of what I was doing.
perhaps a quick-dirty script that rewrites paths on the latest master repo, rather than a patch?
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. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
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?
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
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@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@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/
2012/2/22 Chris Cormack <chrisc@catalyst.net.nz>
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.
With that in mind I've prepared a new set of changes which are ready for testing. As Paul suggested, instead of moving the CSS and JS files I've created a copy of them in the new location, leaving the old files to cover templates which haven't yet been modified. That makes for too large a patch for Bugzilla so you'll have to test by cloning the branch from Gitorious: git://gitorious.org/koha-dev/koha-dev.git The branch is called ip-bug-4048-js-css-libs-path-2012-02-24 See Bug 4048 (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4048) for a detailed commit message. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
participants (5)
-
Chris Cormack -
Marcel de Rooy -
Mason James -
Owen Leonard -
Paul Poulain