As Onno Kortmann wrote: > > But if we do not want reviews, ok, then everybody should check > > in. No problem. I have my local copy :-)
> Well, I do NOT know the policy here for patches and/or check-ins. Is > "compilable" successful enough, should a test suite finish > successfully, should it pass additional review, what is it? > My personal preference is 'compilable & test suite is ok', as this > is 'development quality' code, isn't it? I'm afraid once you (or whoever) committed it to CVS, nobody is ever going to touch it again. So my very personal opinion: it's OK to initially commit "development quality" code (basic requirement: it must compile for everybody), *but* only as long as you continue working onto it until it's got "good quality" (or even "excellent quality"). Otherwise, over time, the quality of the final product will severely suffer. Seriously, Onno, some of your ideas sound really cool, but then, some of your comments make me a little scary as well. ;-) (Like the one explaining that there's still a memory leak within.) For sure, I wouldn't want to have that within a final release myself. As Klaus' response above sounded a little annoyed, and even partially like he might completely abandon this project (at least in public), I continued some private discussion with him. That way, we could handle it in German, which was simply easier for the job. After a couple of emails, his initial annoyance was basically gone, and he assured me that he primarily wants to step back a little, to allow others to eventually step in. He feels all the ideas and patches suggested do require quite a bit of polishing, but he doesn't have the time to perform that kind of polishing within only a few days, so others have to take care of it. Of course, one of his (understandable) hopes is that he'll recognize the project later on so it's not going to become a *completely* different thing. During this discussion, Klaus mentioned me *his* objectives for the project. I felt this being quite important, as it explains a bit the history of the project, as well as the way he maintained it. As Klaus currently cannot read/write emails (for different reasons unrelated to simulavrxx), I asked him for permission to translate that part of his email into English, and repost it to the list: Klaus' really *main* objective is simulator speed. Achieving a good simulation speed counts above all to him; he rather avoided things like "politically correct OO methods" if they adversely affect the simulation speed. (As one of the things that are still quite suboptimal in that respect, he mentioned the LCD simulation. He committed it to CVS anyway, but considers it inferior in terms of speed. Any takers?) His second objective exactness of simulation, including exactness of the timings. The third on his list was stability, and finally, code that is easy enough to understand it again after a couple of years. He also mentioned his #1 item on the feature list, which he sees as a requirement before calling the version 1.0: completeness of the simulation features of an ATmega128. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
