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. 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.
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.
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.
Ingrid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
