On Sat, 5 Jan 2002, Alexander R Angas wrote: > Can I just make a comment about this... in the last two weeks about 2 > million (OK, slight exaggeration) CVS check-ins have been made. This has > been directly before release. Not only has this been virtually impossible to > keep up with, but has been particularly infuriating around this time of year > when I at least have had very little time to check and fix things (most if > not all of us do celebrate Christmas and New Year, right?!). I know > Christoph has time constraints on when we can release but geez...
> The main problems that have been occurring have been with the event sound > server. As I recall, this was never going to be included in release, and > silly me let it go through! (Thank goodness it's not the default.) I know > Matt has great hopes that this server will work better than polled on Win32, > but quite frankly I doubt it will ever work perfectly. We already have a > polled sound server that works almost perfectly which should have had its > slow sound problem fixed for Win32 as soon as it was clear that the timing > problems for the event ss would be too great to fix very easily. You're right there, of course. We should've understood the polled_ss problem instead of replacing it with new ones. > In the event ss, there are too many variables when selecting a value for > timeSetEvent() (you haven't answered my questions about that yet Matt :) ), > and CPU usage is too high (although I'm sure Matt will be able to get this > down). As has been mentioned by people, there are problems with saved games > which I haven't been able to reproduce since I don't have time to play them > a lot and on occasions reproducible instructions haven't been given to me so > I can see what's happening. Sorry, what were your questions about timeSetEvent? The use cases I provided were detailed enough (I thought) to see some of the problems. > Busting our guts to fix the event sound server directly before release was > IMHO a bad idea and only introduced problems when both Matt and I were > working on the event ss files and many commits were occurring around the > same time. I would have a commit all ready to go, then would go on-line and > find that Matt had made great advances which I didn't have much time to test > with my new code. So I re-diffed, checked things still worked briefly, and > checked the code in. This obviously didn't always work! (Especially when I > buggered up merging the code.) Also, in the middle of code freeze week my > computer fell apart and needed rebuilding which took about 5 days!! I totally sympathize with the situation, and I'm not blaming you for the problems we ran into. We just need to be smarter about coordinating the effort, and I suggested a small test plan to run through to prevent more bugs from being introduced into CVS. I held off on working on the event_ss directly for some time simply to avoid problems like the ones you are describing, but I honestly thought we could get it working decently for the release. > I feel it was particularly a bad idea to focus on the event ss when there is > an MCI solution for Win32 which will fix everything, and is only a week or > two away (I started it a little while ago and have all the info I need to > finish it). Like I said, I really thought the event_ss could be made to work decently for the release. > Yes, my commits have been poorly checked. There is no excuse for committing > broken code (especially around release). But hopefully you can see my point. > Can I also just add that I am certainly not blaming anyone here, but perhaps > we got things a bit out of perspective in some areas? Yup, you're right. Maybe we should pick a day/time each week that's convenient so we can hash things out on IRC? This should help us stay synchronized better. In the future, I will avoid doing further checkins to the event_ss areas unless you explicitly ask for assistance, or I explicitly ask you to make sure it's alright. -- http://www.clock.org/~matt
