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
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
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
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
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
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
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
This can start already for 2.90, following this proposed schedule.
Exception for a few developers
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.
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.
And fixed it!
Didn’t know Blender development was so carefully scheduled like this. You guys are really doing good stuff!
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.
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 7 days after the post is published. Feel free to continue the conversation on the forums.