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