After much waiting, and a few surprising issues, gem5-20.0 has been released! The master branch of the gem5 repo now points to the gem5-20 release instead of the gem5-19 release.
Thank you to everyone that made this release possible! This has been a very productive release with 84 issues, about 500 commits, and 30 unique contributors.
Below, I go over the major changes in gem5-20.0 since gem5-19, which can also be found in the RELEASE-NOTES.md file. This should cover all of the major changes and user-facing changes. The hope is that after reading the changelog, you can make updates to your local gem5 changes and then things will just work. I‘m sure this *isn’t* going to be that clean, but we can hope.
First, I want to look at a quick leaderboard of the most prolific contributors for this release. Going forward, I‘d like for these leaderboards to be living and automatically updated on the website. If you’re interested in helping out on this, let me know!
There was a total of 510 commits between the v19.0.0.0 tag and the v20.0.0.0 tag. gem5 v19.0.0.0 was tagged on February 20th, so this release was over 91 days or over 5.5 commits per day! This was quite a breakneck pace!
Having more commits doesn‘t necessarily mean that you’ve contributed more. However, being on this list of the top 10 committers does mean that you've put a significant amount of your time into gem5. For that, the community thanks you!
235 Gabe Black
66 Giacomo Travaglini
46 Bobby R. Bruce
24 Nils Asmussen
21 Adrian Herrera
21 Daniel Carvalho
19 Nikos Nikoleris
14 Matthew Poremba
12 Timothy Hayes
9 Ciro Santilli
Possibly more important than raw commits are the people who take time out of their days to review code. Here are the top 10 reviewers for this commit. Again, thank you for your work! The number of bugs that reviewers find is incredible, and without these people gem5's code quality would suffer.
While there were 510 commits, there were 642 reviews for an average of 1.25 reviews per change. The way we count reviews isn't perfect as it misses “re-reviews” and also skips “Maintainer” reviews. However, I would like to see this review ratio to be closer to 2 reviews per changeset in future releases.
162 Jason Lowe-Power
120 Bobby R. Bruce
76 Nikos Nikoleris
58 Gabe Black
51 Daniel Carvalho
49 Giacomo Travaglini
44 Ciro Santilli
13 Matthew Poremba
10 Chun-Chen Hsu
6 Ayaz Akram
6 Andreas Sandberg
I want to call special attention to this list as there are a number of people who do more reviewing than writing code. This is incredibly helpful to the community, and we appreciate your contributions even if they aren't adding code!
The gem5 community is committed to continually improving its processes based on best-practices and feedback from developers and users. In releasing gem5 20, our second official release of gem5, we have learned some lessons which which we shall take into account when developing future versions of gem5.
The gem5 project abides by a gitflow-inspired development setup where our “master” branch contains the latest release of gem5 at its HEAD, with a separate “develop” branch used for day-to-day gem5 development. Upon a release we create a staging branch from develop. This staging branch is then tested, and fixed if necessary, during which time development continues on the develop branch. Once all major tests are shown to pass, and no additional bugs can be found, the staging branch merged into both the master and develop branches, then subsequently deleted, thus completing the release. We have found, by and large, this policy works in our favor, though there is room for improvement.
For gem5 20, we had a policy of giving users exactly two weeks notice before creating the staging branch, with an additional two weeks given to test and fix errors on the staging branch. Our experience has revealed the two week notice prior to creating the staging was good at focusing the minds of developers, prompting prioritization of desired features for the release, and, overall, improving the churn of patchsets reviewed through our Gerrit code-review system. However, two weeks is, in hindsight, too short a notice for many, and resulted in a large Gerrit backlog from those wishing their features to be incorporated into gem5 20. In future releases, we are going to give a full month notice prior to creating the staging branch. Furthermore, we created the staging branch on a Friday, with the goal of merging the staging branch into the master and develop branches exactly two weeks later (another Friday). We found this led to long weeks of hectic changes, fatigue, and bad moral. Friday releases also have the daunting prospect of work leaking into the weekend, or complaints that aren‘t resolved until the following Monday. Going forward, **we’re going to commit to mid-week releases**.
We have also came to realize that our policy of the staging branch existing for two weeks is needlessly restrictive. Given only testing, bug fixes, and critical last-minute changes are permitted to be incorporated into the branch, we see no reason as to why the staging branch should not exist until its stability and reliability is sufficiently proven. In future releases, the gem5 staging branch shall exist for as long as it takes for tests to run, and bugs exposed by these tests to be fixed. As development can continue on the develop branch, this longer-lived staging branch shall not interfere with other gem5 activities.
In testing on our staging branch, we found some bugs exposed by tests we run irregularly. In particular, and to our surprise, a simple check of building different gem5 ISAs with the set of compilers we officially support revealed many compilation errors. We will therefore aim to regularly test the supported compilers during the development of gem5. We will also continue to improve our testing procedures to run more tests more often, in particular by starting regular nightly builds where larger tests and build processes may be run. Finding bugs earlier, as they appear in our development process, will save us a lot of work compared to finding and fixing bugs later in the staging branch.
Finally, gem5 20 officially supports Python3, as well as being backwards compatible with Python2. We have learned that supporting both Python3 and Python2 is a laborious task, more so than we had anticipated. Significant resources have been deployed to ensure gem5 20 functions with Python3 while still functioning for those who continue to use, the now retired, Python2. This level of support, however, cannot be maintained indefinitely. We are therefore keen to accelerate our dropping of Python2 support in future releases of gem5.
We welcome any other feedback on how to improve this process. Please feel free to let us know on the mailing list or by opening an issue.
scons build/<arch>/out/m5, not make.LinuxX86System or similar SimObject).System are now parameters of the Workload (see src/sim/Workload.py).LinuxX86System are now part of X86FsLinux which is now the workload parameter of the System SimObject.tests/main.py, except for the unittests.--disk-image argument to fs.py is now optional.M5_PATH, but the name of the disk image must be specified.queueMemory is now enqueue.queueMemoryRead and queueMemoryWrite with enqueue to another “special” message buffer named memQueue.*Prefetcher to Prefetcher::*