Mathias Bauer wrote:
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.
Doesn't the current situation show that this is absolutely not the case?
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.
Hm, I would prefer to give the team member a chance to avoid his
repeated failures and to allow and to ask him to check his changes himself.
Oh yes - that could be done by automatic tests - how cool!
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,
The 'careful forces' are not very strong at the moment. And I doubt that
some nice reminders will bring a significant change in behavior here.
But no problem, if we significantly enlarge the stopper phase we can
live with the current behavior also.
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.
What are those actions that are taken currently if someone has brought
to much risk to the master?
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
So who is 'we' in this case? Is it the developer and tester who know
their own module best? Or is it some board of extra privileged people
far away from the concrete bug?
If you believe in the good forces within all of us, then give all of us
the freedom to decide whether fixes go in!
If you don't believe in the good forces then their must be clear
criteria why and when fixes or features will not make it into the release.
Anything else has the smell of arbitrary regime - or is the english term
despotism? Sorry for not being a native speaker.
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.
Maybe we could try that at least? At the moment we are in the vicious
cycle of another and another and another regression in the master. I
consider this worse.
Ingrid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
