Hi Jason, "I think master should be stable"as common case should be to use gem5 and not to dev it.
"I think gem5 should be released three times per year." as I assume there would be too much to digest after one year. Best, On Mon, Dec 16, 2019 at 12:21 PM Tao Zhang <tao.zhang.0...@gmail.com> wrote: > Hi Jason, > > Thanks for the proposal. > > Regarding the branch option for stable release, can we do it by git > tagging? > > I think one-release per year is too long. I prefer three-release per year. > > Thanks, > > -Tao > > > On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power <ja...@lowepower.com> > wrote: > >> Hi all, >> >> As many of you have seen on gem5-dev, we are going to be adding a >> "stable" version of gem5. Below is the current proposal. There are a >> couple of points below where there has not been general consensus >> reached. We would appreciate feedback *from everyone in the community* >> on the points where a decision hasn't been made below. gem5 is a >> community-driven project, and we need feedback to make sure we're >> making community-focused decisions. >> >> We will be introducing a new "stable" branch type to gem5. We are >> doing this for the following reasons: >> - Provide a way for developers to communicate major changes to the >> code. We will be providing detailed release notes for each stable >> release. >> - Increase our test coverage. At each stable release, we will test a >> large number of "common" benchmarks and configurations and publicize >> the current state of gem5. >> - Provide a way for researchers to communicate to the rest of the >> community information about their simulation infrastructure (e.g., in >> a paper you can say which version of gem5 you used). >> >> On the stable version of gem5, we will provide bugfixes until the >> next release, but we will not make any API changes or add new >> features. >> >> We would like your feedback on the following two questions: >> >> **Which branch should be default?** >> >> We can either have the master branch in git be the "stable" or the >> "development" branch. If master is the stable branch, then it's easier >> for users to get the most recent stable branch. If master is the >> development branch, it's more familiar and easier for most developers. >> Either way, we will be updating all of the documentation to make it >> clear. >> >> Please let us know which you prefer by replying "I think master should >> be stable" or "I think master should be development". >> >> **How often should we create a new gem5 release?** >> >> We can have a gem5 release once per year (likely in April) or three >> times per year (April, August, and December). Once per year means that >> if you use the stable branch you will get updates less frequently. >> Three times per year will mean there are more releases to choose from >> (but a newer release should always be better). On the development >> side, I don't think one will be more work than the other. Once per >> year means more backporting, and three times per year means more >> testing and time spent on releases. >> >> Please let us know which you prefer by replying "I think gem5 should >> be released once per year" or "I think gem5 should be released three >> times per year." >> >> >> >> >> A couple of notes to everyone who's been following the discussion on >> the gem5-dev mailing list: >> - We have dropped the proposal for major vs minor releases. Note that >> there was some pushback on having only major releases when this was >> proposed on the gem5 roadmap, but it sounded like the consensus was to >> drop minor releases for now. >> - We will still allow feature branches *in rare circumstances*. This >> will be by request only (send mail to gem5-dev if you would like to >> discuss adding a new branch), and the goal will be integration within >> a few months. All code review will still happen in the open on gerrit. >> The benefits will be >> 1) rebases won't be required as you can just make changes to the head >> of the branch >> 2) many features take more than a few months to implement, so if it's >> not ready by a release it can be pushed to the next >> 3) large changes won't be hidden in AMD or Arm-specific repositories >> and *anyone* will be able to request a branch. >> >> Thanks everyone for the discussions so far! It would be most useful to >> hear back by the end of the week. However, I don't expect any concrete >> actions will be taken until after the holidays. >> >> Cheers, >> Jason >> _______________________________________________ >> gem5-users mailing list >> gem5-us...@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > _______________________________________________ > gem5-users mailing list > gem5-us...@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
