Here are the instructions on how to set the default branch of a Gerrit project: https://gerrit-review.googlesource.com/Documentation/project-configuration.html#default-branch

Call it dev rather than development.

@Jdlrobson points out that it should be as simple as changing defaultbranch from master to dev in .gitreview. See https://m.mediawiki.org/wiki/Gerrit/git-review#What_happens_when_you_submit_a_change for more detail.

So would changing
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend/97476381d917f62ee19ba325f5542559a1614f54/.gitreview
be enough or do we need to change the settings on the gerrit ui too?

We need to make sure that the dev branch is created on each project so that Gerrit will accept the patches (read: yes, essentially)

Change 224086 had a related patch set uploaded (by Phuedx):
Push to dev branch by default

https://gerrit.wikimedia.org/r/224086

Change 224085 had a related patch set uploaded (by Phuedx):
Push to dev branch by default

https://gerrit.wikimedia.org/r/224085

I started this as part of T104558.

Change 227995 had a related patch set uploaded (by Phuedx):
Push to dev branch by default

https://gerrit.wikimedia.org/r/227995

Change 224085 abandoned by Phuedx:
Push to dev branch by default

https://gerrit.wikimedia.org/r/224085

Change 227996 had a related patch set uploaded (by Phuedx):
Push to dev branch by default

https://gerrit.wikimedia.org/r/227996

Change 224086 abandoned by Phuedx:
Push to dev branch by default

Reason:
Superseded by 227996.

https://gerrit.wikimedia.org/r/224086

@phuedx I talked to @Jdlrobson and I've been postponing prioritizing this because looking at the current team situation I'm not sure we would be able to effectively handle more process for PO+TL right now.

Do you guys feel we should do this? We can try it out next sprint if we feel strongly about it, we'll move the defaults on Gather and MobileFrontend, and will manually merge dev head to master on Thursdays or Fridays for example, and generate a change log weekly somewhere.

I need moral support to actually make this move.

Would this mean, that changes doesn't go to the beta cluster after merging them? How would we test changes before they go out in the wild (now we can always link to the beta cluster to test recently merged changes)?

@Florian See T104558. dev would auto-merge every 10 minutes to http://reading-web-staging.wmflabs.org/ as beta cluster does, so you would be able to see your changes live there instantly.

Also a few days before every release (let's say on Friday) the idea would be to forward dev head to master if it is stable enough so that the changes of the week live in beta-cluster for a few (3 + weekend) days before the production cut.

It's something we've wanted to try to see if we would ship less bugs to production by having an actual release process. Obviously if we do it we'll retrospect in a sprint or two and analyze how it is going.

See T104317 for the description of the quarterly goal and T100296 for a long thread of explanations and conversations :D

Change 227995 abandoned by Phuedx:
Push to dev branch by default

Reason:
We'll do this when we have a bit more bandwidth for process changes.

https://gerrit.wikimedia.org/r/227995

Change 227996 abandoned by Phuedx:
Push to dev branch by default

Reason:
We'll do this when we have a bit more bandwidth for process changes.

https://gerrit.wikimedia.org/r/227996

@Florian any thoughts on doing this?

Ok, let me post my (maybe) harsh opinion about that, using the comment of @Jhernandez:

In T104556#1498863, @Jhernandez wrote:

@Florian See T104558. dev would auto-merge every 10 minutes to http://reading-web-staging.wmflabs.org/ as beta cluster does, so you would be able to see your changes live there instantly.

Compared with the overhead this seems to be a bad idea for the already limited resources of reading web. An additional point would be, how do you plan to get more and more visibility and "load" on this clone of our projects? The beta cluster is (as far as I know) tested by a lot of people constantly from time to time (testing new features or just testing something without the need to use a production wiki). In this process, they find erros, bugs and other problems they normally report on phabricator. If we split up the beta cluster to many different projetcs, under different url's with a different configuration compared to the production server, we will differ more and more from the meaning of beta cluster (to have a production near testing area, I remember, that @greg explained that somewhere, too).

Also a few days before every release (let's say on Friday) the idea would be to forward dev head to master if it is stable enough so that the changes of the week live in beta-cluster for a few (3 + weekend) days before the production cut.

That _could_ help, but you still cut of the available time for testing to nearly the half (depends on, when you forward dev to master). Another point is the huge overhead: Who will do the second review (in fact there is already at least one person developing the code, one to review it and now one or a group who look at all changes again)? How much time is planned into the team resources? What are the criteria of approval? Think about that change A was merged before change B, but change B was considered as unstable (for the example it doesn't matter why): Do you want to block change A, cherry pick it to master or what do you want to do (and who will do that, who will do the code review for the cherry pick)? That all will produce a lot of overhead in the development process for something we (in my opinion) take care of already with our beta cluster.

It's something we've wanted to try to see if we would ship less bugs to production by having an actual release process. Obviously if we do it we'll retrospect in a sprint or two and analyze how it is going.

What bugs you try to avoid? I can't remember any bug, that breaks production in a way, that one of our products isn't usable anymore. If you want to try to avoid bugs like "if I click here, it should change the color to green but change it to red" (I hope you understand, what I mean, I mean bugs, which aren't obvious), you will need to invest a lot of work to review all functions in our products every week (or when ever you want to release a new version).

nutshell / tl;dr (whatever)

The idea sounds really good and would make sense, if we wouldn't have a release process already. But we do have something similar with our beta cluster. If we would be more carefully in merging our changes to master (in my opinion we're very carefully already) we could achieve the same goal with less more time and work.

So, the main goal here is to start working on a dev branch by default to allow us to minimise regressions that go out into production. It would have been useful with the recent changes to the fonts, given we are now racing to get a fix for T113759 before the branch cut which was introduced in the fix for T93826. If it was on a dev branch we would have the option of postponing to next deployment but since its on master we don't have control.

I think the staging site and details such as when to deploy still needs to be worked out. Personally I think it would make sense to do a release to master every Tuesday (or every 2 weeks) after the branch cut as this would give us the same length of time to test on the beta cluster. At least then we can sanity check the state of master and release.

I'm suggesting for the time being we try this on Gather since Gather has been pretty stable for some time and see what we learn from that experience. So far it has been useful for QuickSurveys - although it does come with the trade off of slowing down development, which in my opinion is valuable.

This seems fine as long as it's completely optional and people are free to merge to master like they currently do.

Also, it's a bit silly that the same people who were complaining that it takes too long for code to reach production are now complaining that they don't have enough time to test their code before it reaches production.