Talk:Gerrit/Archive 2

While editing commons:MediaWiki talk:Gadget-Cat-a-lot.js, I was pleasantly surprised that the (relatively) new reply tools can automagically convert links to Gerrit/Gitiles into wikitext [[git:...]] during pasting. My input for pasting into the text field was generated by my userscript Gitiles: copy commit reference. The script supports https://gerrit.wikimedia.org/g/ because it's one of the few publicly available instances of Gitiles. This fact was originally just useful for testing, but has now become useful on a Wikimedia project, which is nice.

I see that Changelogs for MediaWiki are generated using Template:Git. Nevertheless, this userscript might be of interest to users of Gerrit/Gitiles.

Here's an example of such "commit reference":

57dac32 (Fix SpecialInvestigateTest to work with SQLite, 2024-06-04)

It is formatted according to Git's pretty format "reference". This format includes not only the commit's hash, but the subject line and a date to make it more robust to changes caused by commit rewrites (e.g. rebases and cherry-picks).

Right now there's a bunch of discussions on how best to configure our IRC feeds in #mediawiki to get people the notifications they want without spamming other users.

Current layout

Project	Bot name	Description
#mediawiki
Gerrit	wm-gerrit	any event from repositories not explicitly sent elsewhere (catch-all). This includes all of mediawiki/*, as well as stuff like test/* and wikimedia/*
Bugzilla	wikibugs	any event from any bug from all products.
SVN	codurr	comment made any dir of any branch in SVN repository "mediawiki" - this is getting more and more quiet as projects move to Git.
#wikimedia-dev
Gerrit	wm-gerrit	any event from repositories matching integration/*
#wikimedia-operations
Gerrit	wm-gerrit	any event from repositories matching operations/* (puppet, mediawiki-config, debs, ..)

Random ideas

• Disabled Gerrit "New review" messages when there is "(no comment)". That notification is triggered when some one change the Verified or CodeReview labels. YDone
  • This should be pretty easy to do.
  • See https://gerrit.wikimedia.org/r/#/c/13146/
• Get wikibugs change reviewed and deployed on production. That would split the bugzilla notifications per product. Changes are in /trunk/tool/wikibugs
  • Ideally we should move this to git as well, but no need to hold up the fix on that.

#wikimedia-dev

We move the bots to #wikimedia-dev, thus we make #wikimedia-dev the developers-only channel (meetings to be moved to another channel), and all #mediawiki users will lose the track of what's going on, but users may be more comfortable getting support if the devs don't abandon the channel (defacto we rename #mediawiki to #wikimedia-dev and most of people who were in #mediawiki will most likely move to -dev).

Separate feed: #mediawiki-feed

We move the bots to the separate channel, which has +m (moderated). That will make all channels more usable for regular talk. But some people will find it difficult because they would have to switch channels more often, as it's not possible to comment on the channel itself but you instead have to followup directly on gerrit/bugzilla or to copy the bot message, paste it on the channel of your choice (one out of the 15+ public IRC channels, plus the private channels, Skype rooms etc.) and comment. However, it would make #wikimedia-dev a duplicate of #mediawiki, allowing to merge it to the latter: we'd have one discussion channel less, and then all the topical/specialised channels as before.

That is similar to the existing #mediawiki-codereview channel. That solution has my preference. Antoine "hashar" Musso (talk) 10:58, 27 June 2012 (UTC)

I think this is the easiest solution, but it's kind of like taking a sledgehammer to the problem. Not to mention the issues that have been raised (not so much the actual switching, but the context being lost between channels). ^demon (talk) 12:32, 27 June 2012 (UTC)

new channel for users

we create new channel for mediawiki help and keep the rest as it is

I would prefer #mediawiki to be the help channel. That is the easiest to remember of and probably the one most people will attempt to join by default. A new channel mean we will have to send people to another channel, leading to some frustration for newcomers / beginners. Antoine "hashar" Musso (talk) 11:00, 27 June 2012 (UTC)

I agree with Antoine. We've been telling people for years that the main channel for support & discussion is #mediawiki. I think either bots or hardcore users can move easier than drive-by contributors. ^demon (talk) 12:30, 27 June 2012 (UTC)

Ok, in that case we should make it bot free, the help channel should not be so much for developers, but people who are seeking help and who don't want to be bothered by some bots who are of no help to them. Petrb (talk) 13:03, 27 June 2012 (UTC)

I'm not sure "bot-free" is the right solution either. We've had bots in there for years, but it's only been in the last couple where it's gotten out of control. Timely, on-topic announcements aren't harmful. Mass spam is. ^demon (talk) 13:06, 27 June 2012 (UTC)

customized feeds

we get all bots to -feed channel, where they send everything and reconfigure them to send only topic related feed to current channels, (mediawiki related stuff to #mediawiki, wikimedia related stuff to #wikimedia-dev) which either make the channels friendlier as well as we would have a relevant stuff in there (I don't understand why #mediawiki devs need to see bugs related to wikimedia platform issues, these should go to -dev). That would mean more spam in -dev and less spam in #mediawiki and more relevant feeds, people who just like to watch spam and flood could stay in #mediawiki-feed. It would involve some people to work on that and change the code of bots, devs are lazy (like me) so this is likely a bad option :)

-feed is to me a duplicate of -codereview . I am not sure what is the point of having another channel to host bots. Just reuse -codereview? Antoine "hashar" Musso (talk) 11:02, 27 June 2012 (UTC)

The complaint is that "codereview" isn't an applicable name if we're sending bug comments (and potentially other things there too). But really, it's just a channel name and isn't worth bikeshedding over right now. ^demon (talk) 12:35, 27 June 2012 (UTC)

Ok. So if we choose that path, we can have -codereview set to redirect user to whatever new channel name is chosen. Antoine "hashar" Musso (talk) 16:31, 27 June 2012 (UTC)

Splitting bug notifications per product is a change in wikibugs source code which is still pending for review :-( Antoine "hashar" Musso (talk) 11:02, 27 June 2012 (UTC)

Middle ground

Project	Bot name	Description
#mediawiki
Gerrit	wm-gerrit	any event from repositories matching mediawiki/* (core, extensions, ..)
Bugzilla	wikibugs	any event from any bug where Product is "MediaWiki" or "MediaWiki extensions".
#wikimedia-dev
Gerrit	wm-gerrit	any event from repositories matching integration/*, operations/mediawiki-config
Bugzilla	wikibugs	any event from any bug where Product is "Wikimedia".
#wikimedia-operations
Gerrit	wm-gerrit	any event from repositories matching operations/* (puppet, mediawiki-config, debs, ..)

May not be perfect, but I'm aiming for improvement of the current situation on the short term. We can always adjust and perfect later. The idea is to minimize traffic in #mediawiki about things not related to MediaWiki core or extensions. Thus keeping traffic on-topic and also reduces confusion to new users by not being confronted with unrelated stuff. Send a little more notifications to #wikimedia-dev to guide discussions about Wikimedia development to this channel instead (which is already the case most of the time, except that notifications were sent to #mediawiki). Effective changes:

• #mediawiki wikibugs: MediaWiki-only
• Wikimedia bugs and wmf-config commits go into #wikimedia-dev.

--Krinkle (talk) 15:02, 27 June 2012 (UTC)

I like this middle ground. I'd maybe add wikimedia/* repos to the -dev channel as well. ^demon (talk) 16:33, 27 June 2012 (UTC)

I like this middle ground as well, it keeps on-topic bot notifications in-channel so we don't lose context when devs are talking with each other about a particular bug/changeset/what have you, but reduces overall noise so less scrollback needs to happen to view a full conversation with someone. --Skizzerz 16:43, 27 June 2012 (UTC)

Not that I'm ever in irc anymore, but +1. I feel a lot would be lost if the bots were totally removed from #mediawiki. Bawolff (talk) 18:09, 27 June 2012 (UTC)

See also

• gerrit/hookconfig.py.erb
• BugZilla: Product/Component overview
• Proposals
  • Bug 46144 - Move wikibugs from #mediawiki to #mediawiki-feed
  • Bug 46282 - Move gerrit-wm to #mediawiki-feed

This post was posted by Krinkle, but signed as ^demon.

https://phabricator.wikimedia.org/T209456 disallowed Gitiles to be indexed due to rogue bots.

Finding Wikimedia code repos hosted on Gitiles can be extremely annoying. Because it doesn't appear that they are indexed by search engines, looking them up returns only their Gerrit changes websites. For example, in order to get to the Mediawiki core Gitiles repo, I search for it , I have to click on the https://gerrit.wikimedia.org/r result because it's the only one, then I have to click "VIEW CHANGES", and then I finally get the "Browse: gitiles" link.

I've faced even more steps when trying to find repos that have very few changes, are small, and are submodules of another repo. For example, it took quite awhile to try the find the value-view Wikibase repo. A Google search doesn't even yield a link to its Gerrit changes site. I did end up finding a link to its JS documentation, however I have no idea how to get from that to Gitiles. I only ended up finding it by looking up a changes that had "value-view" in them on Gerrit, clicking on one, clicking on its repo, and then clicking on Browse: gitiles.

It shouldn't take me this many steps. Gitiles repos should show up in search results in search engines.

In general you should use the Wikimedia Code Search tool to find Wikimedia code, as that is much more powerful than general search engines for this specialised use case.

To answer your question: Yes, at least to some extent. For example, searching on Google or Bing, for 'mediawiki site:gerrit.wikimedia.org/g' provides me with https://gerrit.wikimedia.org/g/mediawiki/core as a result, showing that at least that page is in the index there.

Yes, I also use Code Search, however, sometimes it doesn't give useful results:

Why when I plug in a Gitiles link to an SEO analyzer it says that indexing is not allowed?

Yes, I also use Code Search, however, sometimes it doesn't give useful results:

I don't understand what is not useful about that result?

Why when I plug in a Gitiles link to an SEO analyzer it says that indexing is not allowed?

Because it's blocked from spidering the non-root pages, apparently, since 2013.

I don't understand what is not useful about that result?

idk. I was expecting some other element to have "DvMonolingualTextValue". I guess I don't know jQuery.

Because it's blocked from spidering the non-root pages, apparently, since 2013.

That looks like it was for Gitblit though, which looks like it was for replaced by Phabricator Diffusion and Gitiles. Was that policy just kept on the new systems or is there another reason for blocking indexing on Gitiles?

That looks like it was for Gitblit though, which looks like it was for replaced by Phabricator Diffusion and Gitiles. Was that policy just kept on the new systems or is there another reason for blocking indexing on Gitiles?

Aha, yup, when gitiles took over from gitblit we apparently didn't ban it initially, but it caused a site outage for gerrit, so per T209456 it was added back.

Ok, that's understandable. Thank you for explaining and finding those tasks!

I'm missing a link to a page describing how to handle patches related to security issues.

Given that these shouldn't be uploaded to Gerrit, it's worth mentioning here, especially because I cannot find it anywhere right now.

I eventually found Reporting security bugs#Contributing Patches, but that isn't linked nor does it mention (or link) how to submit those patches!

Even more searching leads to https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Security_patches.

This is worthless, and cost me five minutes I'd rather not waste when dealing with security issues.

I've clarified Reporting security bugs with Special:Diff/4123752/4551271.

Replacement for our Subversion landing page. Use of subpages.

• Describe what git is, link to more info
• How are we using git, link to appropriate workflow documents describing how you clone repo, make change, push it, get it reviewed.

Preferred page layout:

• Git - landing page, very very broad overview
  • Git/Guide - Basic guide to using git. But lets not duplicate docs elsewhere on the web -- keep this appropriate for our users and link generously to outside resources
  • Git/Workflow - describe the workflow for core && extensions (git-review docs here provided we use it)
  • Git/Conversion - move all conversion-related docs here for consistency

This post was posted by Krinkle, but signed as Sumanah.

Even simpler proposal:

1. Merge the content of this page and Gerrit
2. Make this page a #REDIRECT to Gerrit

And then go through the pages under Git/ and either rename to /Gerrit or merge/clean.

Rationale:

We don't need much Git documentation. It is generic and exists elsewhere. The basic Git steps are explained in our Git/Workflow. The rest can be linked.

Most of the documentation we need refers to our code review process, and we can organize that under Gerrit/ . Generic Gerrit documentation also exists elsewhere and we can simply link to that.

Then we have a bunch of content created during the review process and the first days of Git/Gerrit at Wikimedia. A lot of that is simply not very useful or redundant today.

After all that is cleaned we probably won't even need to have 2 extra nav bars.

This post was posted by Qgil-WMF, but signed as Qgil.

Git is now a redirect to this page. Template edited accordingly. Key Git/ pages moved to Gerrit/ (maybe more will be moved as they show up).

What we have:

• Gerrit - needs to be more useful and beautiful.
• Gerrit/Getting started - a shorthand guide.
• Gerrit/Tutorial - Extended play.
• Gerrit/Workflow - I have been removing content duplicated with the Tutorial. Next is also duplication with the Code review guide. What will remain is probably a mix of advanced / troubleshooting tips (and we might just want to call it like that, we'll see).
• Gerrit/Code review - I want to split a guide for pure reviewers (+1 people, all of us) from anything related with +2 and merging. Currently everything is mixed there, with big duplication with Tutorial and Workflow.

There are dozens of pages more, but I believe the basic ones are there, and you can reach the other relevant & updated from these.

This post was posted by Qgil-WMF, but signed as Qgil.

Your explanation helps. Gerrit/Workflow is now Gerrit/Advanced usage, which makes sense. Thanks for cleaning this up!

I fixed the tutorial links on the developer hub page, but it still discusses Git and Gerrit separately. (And it's dead passive voice, "Code review is performed on Gerrit").

This post was posted by SPage (WMF), but signed as S Page (WMF).

See also a proposal to divide the tutorial into separate pages: Talk:Gerrit/Tutorial#Dividing_into_specific_pages.

This post was posted by Qgil-WMF, but signed as Qgil.

Not sure where to add this, but some colleagues have found this script useful:

https://github.com/edg2s/gerrit-sweep

It deletes any local branch that has been merged into master according to its latest Change-Id, so even patches that someone else modified before they were merged get cleaned up (unlike git branch --merged).

Is there any place/repo in gerrit.wikimedia.org where can newcomers upload test commit? Actually for this purose, http://gerrit-test.wmflabs.org/gerrit/#/q/status:open exist. But It does not support ssh upload. So it is meaning less. Because gerrit.wikimedia.org uses ssh commit. Thanks :)

@Petrb: mentioned on wikitech-l the various git/gerrit tip guides, and the possibility of linking them together, and/or merging the best bits into a single (or few) locations.

I've added all the links mentioned so far, to Git/Tips#See also.

Hopefully you folk who understand the contents, can compile the best bits into 1 or 2 locations (either those existing locations, or new pages). E.g. a "complete newcomers guide" (suitable for someone who has basic "editing spelling errors in github" level experience, but has managed to get mediawiki (and etc) installed locally).

Or something along those lines. :-)

The text is currently

To make an anonymous git clone of core MediaWiki you can clone from https://gerrit.wikimedia.org/r/p/mediawiki/core.git or https://git.wikimedia.org/git/mediawiki/core.git

I don't see any value to that second URL. The change is intentional, John Vandenberg commented

add raw git url per last edits by user:Michael Allan; not a bad idea

But AFAIK there's nothing better about git.wikimedia.org, it's just a site running w:Gitblit that we hoped was better for viewing git repos than w:gitweb, though phab:T73974 "Git.wikimedia.org keeps going down". Also I'm pretty sure it won't work for git review, and having multiple remotes causes confusing warnings. So I'm removing it. If there's a reason to give an alternative, explain why it's there.