* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
*
I sympathize with Ali's concerns... the current situation is pretty
much the opposite extreme of the 3-6 month release cycle I was
advocating not that long ago. My main motivation was that a longer
cycle would allow more time for people to find problems, and the
criticism was that a lot of the
I think the bottom line is that as long as you want to do extensive
non-automated testing before declaring something as stable then you
have to have (1) some sort of freeze prior to that point so that your
testers are all testing the same thing (modulo bug fixes) and (2) some
group of people
In the case of some bug fix that needs to be released immediately that
fix could be pushed directly to m5-stable and pulled into m5.
This is an intriguing idea. OpenBSD does this on a 6 month schedule
and it works pretty well. Several other groups (ubuntu for example)
have also started on
I figured we'd make an exception for this month until all the pending
changes get in. We can start the new schedule in July (so the
earliest m5-stable update under the new plan would be ~Aug 1). Should
we should freeze m5-stable where it is now, or if not, when?
Ok, I like that. I think
changeset a9b2504432d1 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=a9b2504432d1
summary: add compile flags to m5
diffstat:
2 files changed, 29 insertions(+)
src/python/swig/core.i |1 +
src/sim/compile_info.cc | 28
diffs (102 lines):
changeset 7c18f61da616 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=7c18f61da616
summary: params: Prevent people from setting attributes on vector params.
diffstat:
1 file changed, 2 insertions(+)
src/python/m5/params.py |2 ++
diffs (14 lines):
diff -r a9b2504432d1 -r
nathan binkert wrote:
We should probably open this discussion up to the m5-users list a bit
to get some feedback and see how many people even plan to track us.
We're likely to want to sync with a stable, well tested, m5 state a few
times a year. Having an m5 stability point every 6 months
On Sun, Jun 15, 2008 at 9:37 PM, Nathan Binkert [EMAIL PROTECTED] wrote:
changeset 758c2413765a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=758c2413765a
summary: port: Clean up default port setup and port switchover code.
[...]
diff -r 7c18f61da616 -r 758c2413765a
