As you may be aware, the reading team was unhappy with its current release process and shared its rationale https://www.mediawiki.org/wiki/Reading/Web/Release_process/experiment#Rationale for a different release process. This resulted in an experiment on Gather, QuickSurveys, Cards and RelatedArticles where the team developed on the dev branch by default. When the team was happy that the dev branch was stable, it would tag a release and merge to master. The idea was to minimise the deployment of incomplete features and SWAT deploys.
This process saw mixed success. Although we felt more comfortable and in control of the code we shipped due to more time for designers and product owners to input into our process it was clear there was an impedance mismatch with the expectations in the MediaWiki developer community and for a small team of 5, we were unable to keep up with the periodic releases of extensions we were not actively maintaining.
As a result we are abandoning this experiment and going back to the Mediawiki Way™ of releasing and merging directly to master.
When we work on new features, we will be more mindful of +2, marking the initial commit of a chain of commits that requires sign off from a designer and product owner with a -2.
We think this will be a better approach for everyone. Our only remaining question is when and if to do release number bumps in future. We'll be back with an answer about that shortly... ideas welcomed.
Thank you for your patience while we experimented and let us know if there is anything else of interest to you in this experiment we have run.
Notes from post-mortem are on wiki https://www.mediawiki.org/wiki/Reading/Web/Notes/2016-Q3_Branching_strategy_post-mortem
Thanks for this writeup (and the wiki page), Jon. Much appreciated.
I only have one question/thought:
<quote name="Jon Robson" date="2016-01-26" time="12:11:05 -0800">
When we work on new features, we will be more mindful of +2, marking the initial commit of a chain of commits that requires sign off from a designer and product owner with a -2.
Wouldn't feature flagging[0], broadly termed, help here?
Other than that, I think you all made the right choice.
Greg
[0] Martin Fowler uses "feature toggle": http://martinfowler.com/articles/feature-toggles.html is a good overview.
On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson jrobson@wikimedia.org wrote:
We think this will be a better approach for everyone. Our only remaining question is when and if to do release number bumps in future. We'll be back with an answer about that shortly... ideas welcomed.
Who is the target audience of release numbers? If it is third-party wikis, they will probably only care about release branches (REL1_26 etc) and you don't have to do anything about that (except backporting fixes for especially nasty bugs), extension branches get split automatically whenever there is a new MediaWiki release.
On the topic of +2 vs. accepting tasks in Scrum, synchronizing the scrum schedule with the release process (so that sprints start on Tuesday and end on Monday) reduces the pain. Although if you use two-week sprints that's probably less useful.
Feature flagging or using feature branches for certain things may be a way to go for certain things, we're keeping that in mind definitely, thanks for the reminder Greg.
I agree with you regarding releases Gergo. The good thing about the *release*s was mainly the curated changelog of changes for that release. A proposal I like is do the changelog every week with the train before the release branch is done. We'll need to establish owners for being effective at doing that.
On Wed, Jan 27, 2016 at 12:43 AM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson jrobson@wikimedia.org wrote:
We think this will be a better approach for everyone. Our only remaining question is when and if to do release number bumps in future. We'll be
back
with an answer about that shortly... ideas welcomed.
Who is the target audience of release numbers? If it is third-party wikis, they will probably only care about release branches (REL1_26 etc) and you don't have to do anything about that (except backporting fixes for especially nasty bugs), extension branches get split automatically whenever there is a new MediaWiki release.
On the topic of +2 vs. accepting tasks in Scrum, synchronizing the scrum schedule with the release process (so that sprints start on Tuesday and end on Monday) reduces the pain. Although if you use two-week sprints that's probably less useful. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
<quote name="Joaquin Oltra Hernandez" date="2016-01-27" time="12:17:38 +0100">
Feature flagging or using feature branches for certain things may be a way to go for certain things, we're keeping that in mind definitely, thanks for the reminder Greg.
Just be clear: feature branches aren't feature flags and take you back to a place closer to a 'dev' branch :).
I agree with you regarding releases Gergo. The good thing about the *release*s was mainly the curated changelog of changes for that release. A proposal I like is do the changelog every week with the train before the release branch is done. We'll need to establish owners for being effective at doing that.
It looks like the release notes[0] are just git short logs, yes? Or is the HISTORY file not what you are referring to (I only did a quick look)?
If it is just the git shortlog, take a look here: eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend
Those pages are automatically created and posted every week with the train, for free (by RelEng).
Greg
On Wed, Jan 27, 2016 at 6:27 PM, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Joaquin Oltra Hernandez" date="2016-01-27" time="12:17:38 +0100">
Feature flagging or using feature branches for certain things may be a
way
to go for certain things, we're keeping that in mind definitely, thanks
for
the reminder Greg.
Just be clear: feature branches aren't feature flags and take you back to a place closer to a 'dev' branch :).
Sure! I was just pointing out two other options that could be considered depending on tradeoffs.
I agree with you regarding releases Gergo. The good thing about the *release*s was mainly the curated changelog of changes for that release.
A
proposal I like is do the changelog every week with the train before the release branch is done. We'll need to establish owners for being
effective
at doing that.
It looks like the release notes[0] are just git short logs, yes? Or is the HISTORY file not what you are referring to (I only did a quick look)?
If it is just the git shortlog, take a look here: eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend
Those pages are automatically created and posted every week with the train, for free (by RelEng).
Nice, we were doing a filtered git log https://www.mediawiki.org/wiki/Reading/Web/Release_process/How_to_release so that's going to work just fine.
Thanks for the help Greg.
Greg
-- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org