Date: Tue, 2 Dec 1997 16:49:58 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: jlemon@americantv.com (Jonathan Lemon) Cc: current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern vfs_aio.c Message-ID: <199712022149.QAA02590@dyson.iquest.net> In-Reply-To: <19971202135015.64574@right.PCS> from Jonathan Lemon at "Dec 2, 97 01:50:15 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Lemon said: > > My gripe is that there wasn't any warning, and it broke some of the other > things that I have (that aren't in the tree). It would have been nice to > have a heads up, and at least an explanation of why the change was being > made (if for nothing else than to reassure people that there _is_ a coherent > design goal for FBSD). There _is_ a design goal, right? :-) > <IMO> Actually, if the change (retval) bothers me at all is that it is different than the way that it used to be done. There are some changes that are self contained, and they don't affect any other piece of code. There are other changes (the retval changes) that affect almost everything, and can make it more difficult (at first) during the transition to write code, because of bugs that are partially due to the change being forgotten about by the other developers. In my case, I remembered about the change, wrote the code for the new method, but didn't recognise the side effect that bit me. That is *my* problem, the developer of other new code, that uses the new methodology. However, developers who do make global changes should weigh the costs and benefits. If the developer isn't sure about his/her position, or wants consultation, they should discuss the modifications with other FreeBSD developers, either privately or publically. (I think that a mix of both public and private discussion is advantageous.) Really significant changes should be discussed with -core, and at least be things that DG feels comfortable with. (Note that DG isn't "boss", but someone has to be the focal point and have the responsibility for the coherency of the software. DG is very very good at that job.) I don't know if PHK discussed the change with DG, BDE, me (I don't remember things very well) or someone else who also has some vested interest in the quality of the code -- but I trust that he did weigh the options. If FreeBSD messes up or his change is a bad idea, it will reflect on him (not only us as a whole.) The peer-pressure method of quality control kind of maximizes our freedom, and still maintains quality. After all of this, one thing that I really want to see us avoid is change for change's sake, and a million lines of diffs for a 0.5% improvement in performance. I think also each of us should be careful to listen to input from other developers (core, major contributors, and the user base), just so we avoid making obvious mistakes very often. </IMO> -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712022149.QAA02590>