* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: FAILED!
* build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/o3-timing:
FAILED!
*
build/RISCV/tests/opt/quick/se/02.insttest/riscv/linux-rv64c/simple-timing-ruby:
FAILED!
*
build/RISCV/tests/opt/quick/se/0
I didn't see anything in the email above about minor vs. major releases.
Was that described somewhere else?
As far as publicizing API deprecation, that could be something we patch
into the preceding release some window before the new release. That could
actually be a good point to grab a snapshot
Ok... so are you suggesting there be no difference between major and minor
releases?
How do you suggest communicating that API changes are coming? The most
common way to do this is by marking functions as deprecated for some period
of time.
Thanks,
Jason
On Thu, Dec 12, 2019 at 4:26 PM Gabe Blac
I think that's what the release vs. development branch split already
provides. If you want stable interfaces, then the release branch will stay
as it is for a year, or forever if you don't move to new releases.
Gabe
On Thu, Dec 12, 2019 at 4:18 PM Jason Lowe-Power
wrote:
> Thanks Gabe!
>
> I th
Thanks Gabe!
I think we're mostly in agreement. The key disagreement is the following:
Note that I'm not advocating for a wild west free for all with no
> accountability, but only being able to make changes to "interfaces" (which
> pretty much everything could be considered) once a year is much t
I'll point out that nobody had to rebase O3 when, for example, the
ExecContext changed, because it was already in the tree and was changed
along with everything else.
I think you have an important contradiction in your reasoning above, namely
that gem5 is simultaneously too unstable and too stable
Hey Abhishek,
Yes! Not only will we be releasing disk images (that we can depending on
license for the benchmarks) and kernel images, we will also be releasing
all of the documentation and the scripts describing how these images were
created. These will also be updated at every release as appropri
Hello Jason,
This is perfect !
I had one more question, for full system simulations will there be release
of images and kernel files for every architectures (arm , x86, etc)?
On Thu, Dec 12, 2019 at 12:57 PM Jason Lowe-Power
wrote:
> Hey Abhishek,
>
> Emails will continue to gem5-dev on every
Hey Abhishek,
Emails will continue to gem5-dev on every changeset pushed to the develop
branch as they do now to master :). We can discuss if we want the same for
feature branches (if we end up using them).
Your first interpretation on gem5 stable is correct (sorry if this wasn't
clear). It will
Hi Jason,
Thanks for your email. It cleared a lot of misunderstanding which I had.
Is it possible to have an email sent on every commit we make to atleast
gem5-dev?
The email list could be different and can be sent to people who are
interested in this so that it does not spam to gem5-Dev list.
I
Hi all,
First of all, let me say that I hope it's clear that gem5 is not
"controlled" in any way by me! As laid out in our governance document (
http://gem5.org/Governance#Overview), "gem5 is a meritocratic,
consensus-based community project". Through these emails, and as the chair
of the project
Daniel Carvalho has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/22610 )
Change subject: mem: Encapsulate mapping gem5 to host address space
..
mem: Encapsulate mapping gem5 to host address spa
Daniel Carvalho has submitted this change. (
https://gem5-review.googlesource.com/c/public/gem5/+/18908 )
Change subject: mem-cache: Move unused prefetches counter update
..
mem-cache: Move unused prefetches counter update
Th
Daniel Carvalho has uploaded this change for review. (
https://gem5-review.googlesource.com/c/public/gem5/+/23567 )
Change subject: mem-cache: Add print function to ReplaceableEntry
..
mem-cache: Add print function to Replace
14 matches
Mail list logo
