Bug Sprints

Building a better Blender

Bug Sprint Proposal – July 2020

This article proposes a new strategy to handle bug sprints during the Blender development cycles. The proposal was met with positive consensus by the Blender maintainers team and will be tried already for the 2.90 release.

Before 2019

bcon1: 2-3 weeks
bcon2: 3-4 weeks
bcon3: 2-3 weeks
bcon4: 1-2 weeks *

Master open - new features for 5-7 weeks
Master closed - bug fixes only for 3-5 weeks

* Release candidate: 1 week per RC - once where were 3 RC
Master closed for undefined periods. Average of 12 weeks release cycle. 3 to 4 releases a year.

Prior to the first 2.80 release, the team would go through the phases of the development cycle at the same time. This made bug sprints a natural stage of the development. A final polishing pass before a new Blender would be out.

However, the unpredictability of the release cycle duration combined with the “narrow” features window lead to many unfinished features rushed in the last minute. This in turn would lead to more bugs and delayed releases. In the end “release candidates” were great, but would also delay a release.

Current system 2019-2020

Overlapping branches so master is always open. 18 weeks release cycle with a 5 weeks overlap. 4 releases a year (1 every 13 weeks).

With the 2.80 release, the overlapping release cycle allowed for master to be always open for new features (good), predictable release schedules (good), but also bugs going unfixed for too long (bad) or introduced at a fast pace.

Proposal for 2020 onwards

bcon1: 9 weeks
bcon2: 4 weeks
bcon3: 5 weeks
bcon4: 1 weeks

Master closed for bug fix only for 2 weeks in bcon2 and bcon3 respectively

Overlapping branches so master is almost always open. 19 weeks release cycle with a 6 weeks overlap. 4 releases a year (1 every 13 weeks).

Shuffling a few weeks around, we can accommodate two bug sprint weeks within a release cycle. The first one as part of the bcon2, to assess and address the critical issues at the backlog and prepare for the beta period. Another one after the beta is out, to handle the issues reported then. This is distant enough from bcon4 so that the reported issues can be fixed for the upcoming release (as opposed to master).

Both bug sprints are also instruments to bring the team together. Blender is a product that concerns everyone involved. Developers should be encouraged to reach out outside their modules/comfort zones and help out whenever is needed.

The bug sprints are also a way to balance the drive to innovate and add new features, with the professional need of stable and mature software. The more features Blender gets, the more potential bugs it will get. Planning for this team-wide is a way to have everyone helping Blender’s overall stability. Besides that, the development and the user community responds well to focused task-forces like this.

The extra week in the release cycle is just to guarantee that the (now) longer bcon3+bcon4 still overlaps with parts of bcon1.

Bug sprint – May 2020

Commits in origin master

Results of the previous bug sprint, 2.83, May 2020. The number of committed bug fixes doubled during the two week long bug sprint.

2 Bug sprints

First bug sprint in the middle of bcon2, to handle backlog.

Second bug sprint in the 2nd week of bcon3 to handle "beta" reports

Splashscreen changes on bcon3.

Once a new release is out, the number of bug reports doubles for a week or two. That lead to many corrective releases in the past. As an example, 2.83.1 got 33 bug fixes ported over, and there are more to come to 2.83.2. To bring back more testing at a specific time – when the new features are more stable (bcon3/beta) – should mitigate that.

To help promoting stronger testing during bcon3, Blender could also get the “2.90” splashscreen in the Beta builds. This should create buzz and drive users for testing. It also adds a healthy pressure to the developers to treat bcon3 as a state where the features should be considered finished, or postponed to the next release (i.e., hidden from the UI and moved to the experimental panels).

By spacing the bug-sprints in two helps developers to plan ahead and clear up their week (EVERYTHING can wait a week for a reply, review, meeting, …). That also prevents burn out by 2 week long bug sprints followed by fixing newly reported high priority beta bugs for bcon3 and bcon4.

There is always a bug sprint lurking around

Overlap of multiple releases in the same timeline

With the overlapping release cycles, there will always be a bug sprint not too far into the future. That makes for a quick assessment of some bugs:

  • Developers see it once, and decide on postponing it to the next bug sprint.
  • They see it again, and postpone it a second time.
  • By the third time they see it, it should be clear whether the bug won’t be fixed any soon (known issue), or should be scheduled in the development agenda.

Either way, it keep the backlog fresh, and the team engaged in a smart use of its time (keep things “agile”).

Blender 2.90

Final planning for 2.90 bug sprints.

Bug sprint week 13-17 July and 3-7 August.

This can start already for 2.90, following this proposed schedule.

Exception for a few developers

Alternative bug sprints planning for 2.90 for few developers, 20-31 July

A few developers prefer to work 2 weeks back-to-back instead. The development team can easily accommodate that in a case by case basis, having them working in the in-between bug sprint weeks.

That said, the team is still encouraged to join efforts at the same time for maximum integration of everyone involved and contributors.

If you have any thoughts or feedback, please share in the comment sections.

  1. Error/mistake spotted.

    > Current system 2019-2020
    > *BCON1 overlaps with previous BCON4
    > 18 weeks release cycle with a 5 weeks overlap
    > 19 weeks release cycle with a 6 weeks overlap

    if the overlap period is given correct (5/6 weeks) then BCON1 has to overlap with previous BCON3 & BCON4.

    Is it a skipped detail/or error?

    • You are correct, BCON1 overlaps with bcon3 + bcon4. I will update the graph, thanks.

  2. Didn’t know Blender development was so carefully scheduled like this. You guys are really doing good stuff!

  3. How about the LTS release cycle being one where Bcon1 only consists of bug fixing? Bcon2 becomes documentation/manual update, Bcon3 becomes finalising the release.

    It would allow the LTS release cycle to be used as a ‘catch your breath’ moment as the team clears down the bug tracker, diff, updates the manual but it also allows the team some breathing space to forward plan up till the next LTS release.

  4. You guys take too much work for growing Blender. 4 release per 1 year. Maybe you need take review and reduce amount of release to 3 and then to 2 per 1 year for better quality and stability.

    Furthermore, feelings from new version of Blender don’t work how it’s must be :)

In order to prevent spam, comments are closed 15 days after the post is published.
Feel free to continue the conversation on the forums.