About a month ago it seemed like that things were heading to the right direction: we had working l10n commit auto-merging and LocalisationUpdate running. That only lasted couple of days and since then things have only gotten worse - neither auto-merge nor LU have been reliably working for almost two months now. We at translatewiki.net get the blame and have to apologize for our translators who are rightfully complaining.
I spent lots of hours on the week and weekend after the switch support l10n commits to Gerrit. While doing that I modernized our repository handling scripts, but the time savings those provide are negated by the fact now someone has get to wrist injury manually accepting all the commits in Gerrit. Not to mention just processing hundreds of repositories is many times slower than one.
Translatewiki.net was also the first big site to switch to Git while *also* having SVN extension around. WMF forced all its extensions to move to Git unconditionally to simplify things. To date there are no scripts to help third party sites maintain their wikis with both Git and SVN extensions.
I've asked many times to announce new repositories and other big changes (like history rewrites) to repositories on wikitech-l, but that is still not happening. For example the recent rewrite of histories of map extensions was unannounced and delayed l10n commits for at least one day, because our scripts don't handle that situation automatically.
Some extension commits go past Gerrit code review. This means that it is impossible to even get notifications on those extensions. Some of those extensions are in use at translatewiki.net and given the numerous breakages related to those extensions lately, I am seriously considering removing those extensions from translatewiki.net until this issue is solved. That is bye bye to maps showing our registered translators around the world.
I am not willing to run code that is both unreviewed and not seen by me. We did talk about this before the migration and I'm very annoyed it happened anyway and that people think this is acceptable [1].
These and other issues are bugging me every day (some of you already know this very well) and I desperately want to get them out of my mind and in to the past.
-Niklas
[1] https://bugzilla.wikimedia.org/36927
On Fri, May 18, 2012 at 12:53 AM, Niklas Laxström <niklas.laxstrom@gmail.com
wrote:
I spent lots of hours on the week and weekend after the switch support l10n commits to Gerrit. While doing that I modernized our repository handling scripts, but the time savings those provide are negated by the fact now someone has get to wrist injury manually accepting all the commits in Gerrit. Not to mention just processing hundreds of repositories is many times slower than one.
While this sounds like a minor annoyance relative to the other issues you are facing, I put together a PHP script called 'dippy bird' that allows you to make arbitrary queries of gerrit from the command line and then take bulk actions on the results (like approving/merging, for instance). It might help you out with this particular problem: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/gerrit-dippybird/
On Fri, May 18, 2012 at 3:53 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
About a month ago it seemed like that things were heading to the right direction: we had working l10n commit auto-merging and LocalisationUpdate running. That only lasted couple of days and since then things have only gotten worse - neither auto-merge nor LU have been reliably working for almost two months now. We at translatewiki.net get the blame and have to apologize for our translators who are rightfully complaining.
Briefly, I think I fixed the L10n issue this morning.
https://gerrit.wikimedia.org/r/#/c/8037/
Regarding extensions skipping review -- I agree this is totally evil and it needs to change *right now*. I'm working on a way for auto-approving of extensions that don't want to be reviewed. I'll have more to say on this during the coming week.
-Chad
Hey,
I'm working on a way for auto-approving
Thanks for all your work on the git stuff :)
of extensions that don't want to be reviewed.
I hope there are very few people that do not want review for their extensions. However, this is not why people need to have automatic merging. The use case is people developing extensions and not being able to wait weeks before important commits of them get reviewed and merged. Many developers in the community work for third parties that want to see results, so if you force developers to wait on review this long, they'll just go use their own repository, and then you end up with way less visibility then you have now even for things that gerrit is to dumb to show in it's list of merged changes.
Quite different motivation then not wanting changes to be reviewed ;)
Thinking about it, it would be nice to have a working post-commit review workflow like we used to have, for those projects where gated trunk does not work due to lack of quick review.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Sun, May 20, 2012 at 12:38 PM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
I hope there are very few people that do not want review for their extensions. However, this is not why people need to have automatic merging. The use case is people developing extensions and not being able to wait weeks before important commits of them get reviewed and merged. Many developers in the community work for third parties that want to see results, so if you force developers to wait on review this long, they'll just go use their own repository, and then you end up with way less visibility then you have now even for things that gerrit is to dumb to show in it's list of merged changes.
Quite different motivation then not wanting changes to be reviewed ;)
Fair enough. But the end result is the same :)
Thinking about it, it would be nice to have a working post-commit review workflow like we used to have, for those projects where gated trunk does not work due to lack of quick review.
I'm open to suggestions here. We could write some custom approval/review rules in Prolog for extensions that want them (put them in rules.pl on the refs/meta/config "branch")
-Chad
PS: Here's the default review rules http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
On Sun, May 20, 2012 at 12:55 PM, Chad innocentkiller@gmail.com wrote:
PS: Here's the default review rules http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
Make that http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
On Sun, May 20, 2012 at 1:15 PM, Jeremy Baron jeremy@tuxmachine.com wrote:
On Sun, May 20, 2012 at 12:55 PM, Chad innocentkiller@gmail.com wrote:
PS: Here's the default review rules http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
Make that http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
Indeed. Totally missed that typo, thanks.
-Chad
On 20/05/12 19:15, Jeremy Baron wrote:
On Sun, May 20, 2012 at 12:55 PM, Chad innocentkiller@gmail.com wrote:
PS: Here's the default review rules http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
Make that http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
I guess you were not jokingly proposing to write a hook in http://en.wikipedia.org/wiki/Prolog, then.
On Sun, May 20, 2012 at 1:45 PM, Platonides Platonides@gmail.com wrote:
On 20/05/12 19:15, Jeremy Baron wrote:
On Sun, May 20, 2012 at 12:55 PM, Chad innocentkiller@gmail.com wrote:
PS: Here's the default review rules http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
Make that http://code.google.com/p/gerrit/source/browse/gerrit-server/src/main/prolog/...
I guess you were not jokingly proposing to write a hook in http://en.wikipedia.org/wiki/Prolog, then.
I was not. Writing our own rules in Prolog wouldn't be the *easiest* course of action probably, but it is the most robust/flexible. Worth investigating at least.
-Chad
On 20/05/12 18:38, Jeroen De Dauw wrote:
Thinking about it, it would be nice to have a working post-commit review workflow like we used to have, for those projects where gated trunk does not work due to lack of quick review.
Cheers
gerrit seems to be all for pre-review, yet I think we should use a tool which supported post-review, too. (Note for the review-tool evaluation) Currently, there's no way to mark as fixme a revision which already got into the repository.
On Sun, May 20, 2012 at 5:13 PM, Platonides Platonides@gmail.com wrote:
Currently, there's no way to mark as fixme a revision which already got into the repository.
There's also way to have followups (including reverts) with good metadata and UI. You can make comments or commit msgs that mention the other change ID but there's no dedicated place on the page to list relationships to other changes.
On Sun, May 20, 2012 at 9:38 AM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Thinking about it, it would be nice to have a working post-commit review workflow like we used to have, for those projects where gated trunk does not work due to lack of quick review.
Would it help if we implemented a "unreviewed" branch that Jenkins automatically pushes to after verifying that the code works? We'd still want master to remain the way it is, but it seems like it might be cool to have a branch that works much the way the old post-commit review worked. It would mean more visibility for unreviewed code, since it'd be much easier for everyone to pull in all of the unreviewed code into their working repos.
I have no idea how easy/feasible this is, but throwing this idea out there as something that might be helpful.
For deployed extensions, it's pretty tough to go back to the post-commit model, since that would also mean going back to the far less predictable deployment schedule.
On Sun, May 20, 2012 at 2:13 PM, Platonides Platonides@gmail.com wrote:
gerrit seems to be all for pre-review, yet I think we should use a tool which supported post-review, too. (Note for the review-tool evaluation) Currently, there's no way to mark as fixme a revision which already got into the repository.
It would be so nice to also have post-commit tagging system. Still an open feature request for Gerrit: http://code.google.com/p/gerrit/issues/detail?id=287
...which we may need to pitch in a patch for if we ever want to see it implemented.
Rob
Some extension commits go past Gerrit code review. This means that it is impossible to even get notifications on those extensions. Some of those extensions are in use at translatewiki.net and given the numerous breakages related to those extensions lately, I am seriously considering removing those extensions from translatewiki.net until this issue is solved. That is bye bye to maps showing our registered translators around the world.
I think that having commits to extensions unreviewed is a good thing for their maintainers. Auto-approval looks like a workaround.
I have a question here since I am not sure I fully understand the problem: how are you getting notifications that i18n files have changed?
From gerrit or git? I think it should be the latter (some git hook).
//Saper
Am 21.05.2012 18:41, schrieb Marcin Cieslak:
I have a question here since I am not sure I fully understand the problem: how are you getting notifications that i18n files have changed? From gerrit or git? I think it should be the latter (some git hook).
From Gerrit. Manually opening every merged commit from core [1] and extensions [2] in a new tab and looking for i18n related changes.
Raimond.
[1] https://gerrit.wikimedia.org/r/#/q/mediawiki/core+status:merged+branch:maste...
[2] https://gerrit.wikimedia.org/r/#/q/mediawiki/extensions+status:merged+branch...
wikitech-l@lists.wikimedia.org