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.