Le 27/03/12 11:57, Niklas Laxström a écrit :
I have been collecting list of issues at http://www.mediawiki.org/wiki/Git/Conversion#Open_issues_after_migration
I'd like start discussion how to solve these issues and in what time frame.
I would really prefer that we add issues in the Bugzilla tracker. We already have enough mess to keep track of and a wiki has already proven how bad it is for issues tracking.
I am answering below but will not follow up. We should have bug opened for all issues potentially copy pasting from this mail and my answer.
== Code review process == I would very much like to have the full patch diffs back in emails so that I can quickly scan for any i18n issues. Also Gerrit is just slow enough that I must either waste time waiting for it to load the interface, or do a context switch by reading next commit. Not to mention the need to open the diffs for each file in tab.
<snip>
There are several issues in that paragraph.
Full diffs in emails:
I dislikes having full diffs in emails and they are lacking colors making them basically useless to me. That also makes mail processing slower and makes my inbox very huge. If we ever do that, please please make it a per user option.
Gerrit slowness:
I do not have that much an issues. Possible root causes could be: - you have a slow computer - your network connection is bad - Gerrit client interface is badly programmed - Gerrit server is overloaded Or that might just be because delay between click is not good enough for you. Maybe we could investigate on the server side or add a layer of caching in front of Gerrit. Anyway, something worth a bug so we could investigate it.
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.
diff files in each tab:
I am a huge fan of this feature, I find it way easier to handle than a large and long page. I have already written about it in wikitech-l some weeks ago. One possible workaround would be to add a link to the Gitweb full diff in Gerrit GUI.
This should probably be reported upstream.
== Emails == Related to above, I want to scan all (submitted?) changes for the issues. Currently there is no easy way to subscribe to changes of all repositories.
Indeed, you have to manually subscribe to get email notifications for each projects. Once subscribed you will always receive everything with no easy way to stop the mail spam even if you have no interest in a specific change. As I understand it, you are looking for something like the mailing list that received all mediawiki svn commits. We will have to look at Gerrit to have some mailing list to get notified of any patchset submitted to Core and Extension.
Need investigation and a report upstream.
In theory I could do the same inside Gerrit, would it provide a easily navigatable list which records what I have looked at.
One way is to use the Gerrit search box and look for 'mediawiki/' that will give you all changes ever submitted to mediawiki/* projects.
== Unicode issue in Gerrit == This must be fixed (dataloss). See https://gerrit.wikimedia.org/r/#change,3505 for example
See: https://bugzilla.wikimedia.org/35455
Upstream recommendation is to use the embed H2 database or a real database such as postgre.
== 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.
== 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
Thanks Niklas for your long feedback :-)