See https://phabricator.wikimedia.org/T120581#1888351 my suggestion is that we should not switch back to the master branch for development and try and get these two things compatible.

This then becomes a question of how we keep on top of releases. Personally I think we have 2 options

1. We designate a certain day or days as "Release days"
2. We create an automated tool that creates patches against master when a certain threshold is met e.g. a dev branch is a multiple of 3 commits ahead of master. By showing up in Gerrit they become more obvious

We can check the status of a release as follows:

git fetch
git log HEAD..origin/dev --oneline

If the result is not empty a release is needed.

Some examples:
QuickSurveys - https://phabricator.wikimedia.org/P2436
RelatedArticles (up to date)
Gather - https://phabricator.wikimedia.org/P2437

So guys - tools or manual jobs? Thoughts?

(random $0.02USD in from outside the team)

In T120264#1888421, @Jdlrobson wrote:

This then becomes a question of how we keep on top of releases. Personally I think we have 2 options

1. We designate a certain day or days as "Release days"

Like "Tuesday" (i.e. the day that the WMF train deployments run)?

I've read https://www.mediawiki.org/wiki/Reading/Web/Release_process and to some extent I question the wisdom of the decision to use a non-master development process. I have some sympathy and understanding for the desire to demo and review easily with stakeholders and I can see how the isolated staging system facilitates that. I also fear however that such a system leads to having the same problems ultimately when there are multiple streams of work in progress and stream A is ready for release and stream B is not but both are landed in the dev branch.

Running 2 week sprints with a goal to produce a shippable increment at the end of the sprint when the WMF deployment cadence is 1 week can be awkward. Ideally I'd like to see everything that everyone does be continually releasable and for the production deployment cadence to move to continual deployment. That's a big culture and tech shift however.

The current use of a process that is detached from deploy train also seems like it will cause differences in expectations between the team and the larger community when working on features that cross multiple repositories and involve projects like MediaWiki core that are not going to pause to make sure that Reading Web is happy with all changes before moving forward. As the team's focus shifts farther and farther from isolated feature work in dedicated extensions it seems like this will become more pronounced.

We create an automated tool that creates patches against master when a certain threshold is met e.g. a dev branch is a multiple of 3 commits ahead of master. By showing up in Gerrit they become more obvious

Wouldn't this defeat the purpose of the dev branch? We wanted to have a full control over when to release our code and with this automated tool we're not in control anymore.

I also think that we should switch back to master and use our development branches to show off new features. For example, I work on a new feature on my branch, I pull it to a staging environment and make it available for testing, once both product owner and the reviewer are happy with the code and product, we can merge the patch to master.

In T120264#1894184, @bmansurov wrote:

We create an automated tool that creates patches against master when a certain threshold is met e.g. a dev branch is a multiple of 3 commits ahead of master. By showing up in Gerrit they become more obvious

Wouldn't this defeat the purpose of the dev branch? We wanted to have a full control over when to release our code and with this automated tool we're not in control anymore.

To clarify my idea was we would still be responsible for merging. It would just act as a reminder. Whether that's useful or not is up for discussion.

I also think that we should switch back to master and use our development branches to show off new features. For example, I work on a new feature on my branch, I pull it to a staging environment and make it available for testing, once both product owner and the reviewer are happy with the code and product, we can merge the patch to master.

In T120264#1888421, @Jdlrobson wrote:

See https://phabricator.wikimedia.org/T120581#1888351 my suggestion is that we should not switch back to the master branch for development and try and get these two things compatible.

This then becomes a question of how we keep on top of releases. Personally I think we have 2 options

1. We designate a certain day or days as "Release days"
2. We create an automated tool that creates patches against master when a certain threshold is met e.g. a dev branch is a multiple of 3 commits ahead of master. By showing up in Gerrit they become more obvious

We can check the status of a release as follows:

git fetch
git log HEAD..origin/dev --oneline

If the result is not empty a release is needed.

Some examples:
QuickSurveys - https://phabricator.wikimedia.org/P2436
RelatedArticles (up to date)
Gather - https://phabricator.wikimedia.org/P2437

So guys - tools or manual jobs? Thoughts?

3. Change or stop using the release process for extensions that we're not actively developing – to bang on the Responsibility/Focus drum once again: we should always be mindful of the number of extensions that we're responsible for, are not being actively developed, and are in production
4. Deploy feature branches to reading-web-staging and drop the team-wide dev feature branch

Either choice requires that we publicly state that development of the extension and its features has stalled, which, IMO, is a Good Thing™.

In T120264#1888577, @bd808 wrote:

(random $0.02USD in from outside the team)

In T120264#1888421, @Jdlrobson wrote:

This then becomes a question of how we keep on top of releases. Personally I think we have 2 options

1. We designate a certain day or days as "Release days"

Like "Tuesday" (i.e. the day that the WMF train deployments run)?

I've read https://www.mediawiki.org/wiki/Reading/Web/Release_process and to some extent I question the wisdom of the decision to use a non-master development process. I have some sympathy and understanding for the desire to demo and review easily with stakeholders and I can see how the isolated staging system facilitates that. I also fear however that such a system leads to having the same problems ultimately when there are multiple streams of work in progress and stream A is ready for release and stream B is not but both are landed in the dev branch.

Running 2 week sprints with a goal to produce a shippable increment at the end of the sprint when the WMF deployment cadence is 1 week can be awkward. Ideally I'd like to see everything that everyone does be continually releasable and for the production deployment cadence to move to continual deployment. That's a big culture and tech shift however.

I've always been a fan of feature flagging new development work, allowing code to be deployed and released to users (or better yet, groups of users) separately.

I agree with all of you.

That said, I'm not sure how to proceed. We don't want in progress work in master to be deployed to production and cause problems to our users... and that's what using master gives us (staging for signoff (beta cluster) == will ride the train really soon)

In T120264#1894184, @bmansurov wrote:

I also think that we should switch back to master and use our development branches to show off new features. For example, I work on a new feature on my branch, I pull it to a staging environment and make it available for testing, once both product owner and the reviewer are happy with the code and product, we can merge the patch to master.

That's an interesting take, the problem I see is that then we would have both in progress feature work from different topics in dev, so when merging to master it would probably mean also merging other in progress work from other things not yet ready to be merged. This seems like a no-go to me.

Also, +1 to @phuedx. Extensions getting stale because we're not releasing is a sign that we're not actively maintaining that extension and as such you should not expect frequent releases. I don't think it is a bad thing by itself.

@bd808 made a good point too. Maybe it would be worth switching back to master default, now that we have browser tests running on patches. Thoughts?

I mainly agree with @phuedx on this point. I think keeping "stalled" extensions on master is the right way to go. I also think isolating features is important on "active" extensions, but the convenience of the automatic staging of dev is super useful as well.

Not sure on the technical feasibility, but maybe remote sub-branches of dev for features, which get merged to dev when they're ready to go on staging and then individually cherry-picked to master instead of merging dev in?

It looks like everyone has an opinion. Are we trying to reach consensus about our release process in this task? Or is the task done and dusted?

I'm happy to switch back to master when we are not doing active development. We'll need to define what "Active development" means though. I worry about non-i18n changes rolling out though during this non-active development time.

Is QuickSurveys in active development right now?

This doesn't help with translations for features in development unfortunately until T120581 is resolved.
Let's have a talk about this in person over coffee.

I don't think we came to a conclusion about this over coffee but I'm for switching back to master.

Now that we're regularly working on more extensions, I would also suggest that we consider feature branching per-feature rather than always keeping an effective feature branch open.

Let's organise a 30 minute meeting, of which the outcome should be "Let's figure out a branching/dev strategy that includes a solution to 'The i18n Problem."

As a note, I chatted with @phuedx about developing on feature branches (git review whatever-feature) so that when the change is merged it is not merged into master.

This way, i18n rolls master, and we merge the feature branches to master when we think we are ready.

I can't see any big problems with this approach instead of the master one:

• It avoids in progress work without sign-off rolling the train in master
• Gives us control on when we want to merge and roll the train to production
• i18n commits go to master normally
• Releases are cut from master

Some cons:

• We need to figure a way for changing the branch on staging for the PO to sign off (php script on mw that does it?)

Food for thought for the meeting. Any more cons we can think about?

Further cons:

• More potential for rebase issues when merging to master (manageable)
• No i18n whilst work is on a feature branch
• I assume all bug fixes would go to master as would volunteer patches meaning we'd have to be more wary of signing these off

I think using feature branches would certainly help us as a team building new features. It might be a good compromise.

I've set up a meeting for Thursday. Let's work something out and then get this closed out.

We had a meeting. A meeting was had. The rough notes are here. We'll be sending an update to mobile-l soon.

After reading up, I'm in agreement with the decision made at that meeting.

I sent a draft memo to our internal list. Please comment on draft so I can publish it and close this out.

Waiting for email to be sent, almost everybody responded to draft.