Hi Ingrid, > Two problems here. The worst one is that you cannot control that this > new rule is applied. Who decides that a code change is too huge to risk > it for the next release in two months or so? You won't count lines, > don't you - that would be stupid. Those who are willing to act carefully > are doing that already I am convinced. And those who are not acting > carefully you cannot control really with this new rule. So introducing > this new rule will basically change nothing.
I beg to disagree. Of course, as you point out, there cannot be a definite rule of what change is "too big" in which release phase. But alone raising the awareness that large code changes are Bad (TM) after feature freeze might help. And if the analysis of current show stoppers reveal that a significant mount is caused by late big code changes, this is a good argument I'd say. So, let's not call this "rule" as it "if you don't follow it, you'll be shot." I'd consider it a guideline which every reasonable developer would usually follow. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
