Ingrid Halama wrote: > Martin Hollmichel wrote: >> Mathias Bauer wrote: >>> Ingrid Halama wrote: >>> >>> >>>> This is not sufficient. Heavy code restructurings and cleanups are >>>> not bound to the feature freeze date, >>> Perhaps they should? And at least as far as it concerns me they are. >>> >> yes, I also consider large amount or new, move or restructured code as >> a feature and had erroneously the expectation that this is already >> common sense. If all agree we should add this to the Feature Freeze >> criteria (http://wiki.services.openoffice.org/wiki/Feature_freeze) > Two problems here. The worst one is that you cannot control that this > new rule is applied. Well, of course you can control that - at least after the fact if that breaks. :-)
Of course you can't enforce this rule, as is true for most rules I know. Bank robbery is strictly forbidden, but people still do it. But be sure, if it wasn't forbidden, much more people would do it. It's common sense that having rules that work towards the goal is good, even if you can't enforce them always. > 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. This is a matter of how teams work. In general I would give everybody the credit of being able to judge whether his work imposes a huge risk on the product or not. If a team member repeatedly showed him/herself as unable to do that, the team should address that in a way the team sees fit. The idea of being bound to (trapped into?) a rules set that can and must be enforeced all the time is not my understanding of how we should work together. Many problems can be solved or at least reduced by appealing to the "good forces" in each of us, our skills, our will to do the right thing and our pride about our work. Sometimes it needs some reminders, and rules come in handy here. But you never can't enforce all rules you make in a free community, perhaps you can do that in prison. The community as a whole must take care for the value of rules, each member by following them and all together by reminding others and taking action in cases where the rules have been violated. > The second problem is that sometimes bad bugs even detected later in the > phase need bigger code changes. In my opinion only very experienced > developers are able to make serious estimations whether the fix is worth > the risk or not. So what to do now? Should we make a rule 'Let a very > experienced developer check your code'? Sometimes I wish that but I am > not sure that it would scale and - how would you organize and control > such a rule? We have a similar rule for the show stopper phase (let you > change be reviewed by a second developer), but even that rule is > violated often I am convinced. You tell us that we don't live in a perfect world and that indeed some rules don't apply always. Yes, true, but at least for me that isn't really new. Of course we must do a risk assessment in some cases that - due to other measures we have taken - hopefully will happen less often in the future. And risk assessment itself is risky (developers like recursions ;-)). But in case we are unsure, we could move a bugfix that looks too risky but isn't a showstopper to the next release. Instead of asking if someone can judge whether a fix is too risky, let's put it the other way around: something is too risky if you can't say with good confidence that it's not. Does that need an experienced developer? I would expect that it's easier for the less experienced developer to answer that question! But anyway, we will fail here at times, sure. No problem for me, if the number of failures drops to an acceptable level. We don't need a panacea and I doubt that we will ever find one. > So I would like to see mandatory automatic tests that detect whether the > important user scenarios still work properly, whether files are still > rendered as they should, whether the performance of the office has not > significantly decreased, .... . We have a lot tests already even if > there is much room for improvement. In principle some of the tests are > mandatory already, but this rule gets ignored very often. > The good thing is that a violation of this rule could be detected > relative easily and thus used as a criterion for nomination. More testing on the master(!) would be very welcome. But on the CWS? This will make the "time to master" even longer and then again we are in the vicious cycle I explained in my first posting in this thread. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
