Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- I think master should be stable - I think gem5 should be released three times per year Regards,Daniel Em segunda-feira, 16 de dezembro de 2019 22:33:14 GMT+1, Bobby Bruce escreveu: * I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power 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-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-...@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
* I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power 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-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- "I think master should be stable" - "I think gem5 should be released three times per year." Matt On Mon, Dec 16, 2019 at 1:57 PM Abhishek Singh < abhishek.singh199...@gmail.com> wrote: > Hello Jason, > Thanks for such a nice and detailed explanation. > My votes are as follows: > > > *I think master should be development* > > > *I think gem5 should be released once per year* > > > Best regards, > > Abhishek > > > On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power > 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-dev mailing list > > gem5-...@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
Hello Jason, Thanks for such a nice and detailed explanation. My votes are as follows: *I think master should be development* *I think gem5 should be released once per year* Best regards, Abhishek On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power 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-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users