Christian MICHON wrote:
First rule of (efficient) engineering: <<if it is not broken,
do not try to fix it>>
for the record: gcc-3.3-x is *fine* and *most* stable,
not just on windows. It's still my reference compiler
even for linux kernels.
Why do you feel it's necessary to upgrade? Because
gcc people do?
Don't get me wrong, Christian. I don't advocate using the
bleeding-edge latest snapshot from CVS as your full-time reference
compiler. At the same time, you can't lag behind indefinitely without
risking irrelevance. The 3.4.x generation of GCC is several months old
now (much older if you consider release candidates). If it's not yet
time to target 3.4.x as an officially supported compiler, it is AT LEAST
time to start discussions on a timetable/strategy for doing so.
I was unaware that QEMU works properly when built with GCC 3.3.x...
is that a true statement, or am I reading too deeply into your email?
If it is true that QEMU builds on Win32 with GCC 3.3 but not 3.4, then
the "qemu-doc.html" file at the very least should be updated before the
next release. That doc simply says "Install the current versions of
MSYS and MinGW"... which has meant GCC 3.4.x for some time now.
Now that for the first time on win XP hosts we get
decent speed, unless patches are really a must, I do
not intend personnally to upgrade at every snapshot
my current version of qemu.
I feel the same way. I don't plan to upgrade the "production" QEMU
environment I run my virtual machines in every time there's an
incremental upgrade. However, I do plan to build every release for
testing until the issues we're discussing are resolved, and I'm sure I
will periodically upgrade my main QEMU environment.
I don't think that chasing the bleeding-edge is a practical
approach. I also don't think that expecting the world to stick with GCC
3.3 and QEMU 0.6.0 forever is feasible either. I'm advocating what I
believe is reasonable middle ground. This type of discussion is EXACTLY
why most seasoned open-source projects eventually evolve into "stable"
and "unstable" branches... so the project can simultaneously meet your
goal of providing a reliable current release, while providing a
framework to meet my goal of adapting new things into the project
incrementally. Again, I'm just trying to start a discussion.
In short: there is a team out there. Or this mailing list
would be dead.
No offense intended, that was a poor choice of phrasing on my part.
What I was trying to figure out was whether multiple people are writing
code for the project, either through direct source-control access or
sending patches to Fabrice, or if the team's role is more supporting
Fabrice's coding efforts through QA testing and advice/feedback.
Most open-source projects I've been involved with are so STARVED for
volunteers willing-and-able to actually write code, I was surprised last
week when I offered to write a patch and the response was dead silence.
I'm just trying to get a feel for how the project operates, I hope that
my enthusiasm doesn't come across the wrong way.
Steve
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
