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 v220.127.116.11 tag and the v18.104.22.168 tag. gem5 v22.214.171.124 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
LinuxX86Systemor similar SimObject).
Systemare now parameters of the
LinuxX86Systemare now part of
X86FsLinuxwhich is now the
workloadparameter of the
tests/main.py, except for the unittests.
fs.pyis now optional.
M5_PATH, but the name of the disk image must be specified.
enqueueto another “special” message buffer named