Jump to navigation Jump to search

About this board


Krinkle (talkcontribs)

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.

Qgil-WMF (talkcontribs)

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.


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.

Qgil-WMF (talkcontribs)

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.

SPage (WMF) (talkcontribs)

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).

Qgil-WMF (talkcontribs)
ESanders (WMF) (talkcontribs)

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

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).

Reply to "Gerrit-sweep"
Jayprakash12345 (talkcontribs)

Is there any place/repo in where can newcomers upload test commit? Actually for this purose, exist. But It does not support ssh upload. So it is meaning less. Because uses ssh commit. Thanks :)

Reply to "Test Commit"
Quiddity (WMF) (talkcontribs)

@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. :-)

Reply to "git/gerrit tip guides"
Krinkle (talkcontribs)

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
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.
Gerrit wm-gerrit any event from repositories matching integration/*
Gerrit wm-gerrit any event from repositories matching operations/* (puppet, mediawiki-config, debs, ..)

Proposed layout

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. YesYDone
  • 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.


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
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".
Gerrit wm-gerrit any event from repositories matching integration/*, operations/mediawiki-config
Bugzilla wikibugs any event from any bug where Product is "Wikimedia".
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

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

Reply to "IRC"

remove alternative remote

SPage (WMF) (talkcontribs)

The text is currently

To make an anonymous git clone of core MediaWiki you can clone from or

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, it's just a site running w:Gitblit that we hoped was better for viewing git repos than w:gitweb, though phab:T73974 " 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.

Reply to "remove alternative remote"
There are no older topics