On 28/03/12 18:10, Antoine Musso wrote:
scan for i18n:
Can this be somehow scripted / made more automatic? We should probably eastablish a list of recurrent issues then have a script to automatically analyse files to find possible culprit. Two possibles examples comes to mind:
- messages being added in MessagesEn.php and missing from
Messages.inc. 100% sure this can be scripted
- wfMessage() being used without an explicit formatting call (->parse,
->parseAsBlock(), ->text()). There is again 100% possibility to script that using PHP tokenizer.
How would you script that if you don't have the files? (as they are pending a merge) Could we have a branch which included all non-abandoned patches? Or maybe all patches whose total feedback is not negative.
== Local changes == How to handle permanent local changes? There have already been suggestions:
- use git stash (not fun to do for every push)
- use git review --no-rebase (no idea if this is a good idea)
- commit them to local development branch (but then how to rebase
changes-to-commit to master before pushing?)
I have talked about it with Niklas and have no idea how that could be fixed. Maybe by working in a local branch and then have the current commit to be merged to a clean master before submission. That would require some scripting.
Niklas, I guess you want to send a new mail to wikitech-l so it receives more attention.
Maybe by developing on a clean repository, from which you pull to the with-patches one?
== How to FIXME == We need a way to identify *merged* commits that need fixing. Those commits should be our collective burden to fix. It must not rely on the reporter of the issue fixing the issue him/herself or being persistent enough to get someone to fix it.
I was suggested to use bugzilla, but it's a bit tedious to use and doesn't as-is have the high visibility like FIXMES used to have.
We should have less fixme nowadays since we have adopted a pre merge review, it still happens from time to time though. Our bug report is https://bugzilla.wikimedia.org/35535
Can someone measure at CodeReview the number of revisions which went to fixme after having been on ok? gerrit system allowing pre-review doesn't help with the 'false review rate'. There *will* be bugs which get merged into the main repo. Not every master status will be perfectly stable, as we wish it were. Ability to mark the patchsets as fixme is a good tool. If we had a list of follow-ups in gerrit, that would also be useful.