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 <gti...@wikimedia.org> wrote: > On Tue, Jan 26, 2016 at 2:11 PM, Jon Robson <jrob...@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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
