Re: Beyond GCC 3.0: Summing Up

[dewar at gnat dot com]

<<I wonder if there is some difference between people who manage companies
and normal people; perhaps Robert and I are in some weird pointy-haired
boss mode here.
>>

Perhaps :-)

The real point is that any reasonable process here requires some
centralization of decision making on whether patches need to be reverted
because of overall judgments covering all targets. It is unreasonable
to expect the originator of a patch to have the perspective or knowlegde
to make this judgment (in the gcc environment, the originator does not
even necessarily have the information in a timely manner, since we do
not have a systematic rapid testing protocol over all targets).

Going back to the case of GNAT. If we get a regression, it can range from

a) completely unimportant, either the case is pathological, or there is
a change of behavior and the new behavior is acceptable, or the issue
is simply a slight change in output format that we judge will not affect
anyone, or an error message that is different, and either as good, or
only slightly worse.

b) critical, we can see from the test case that is failing that this will
affect an important customer, or we can estimate that it is likely that this
will cause serious problems. This is all the more true if the result of the
regression is to generate bad code silently.

For a) we definitely do not need to revert, the new regression goes into
the list of old regressions for the target, and is assigned like any other
known bug, or is judged to be acceptable behavior, and the base line for
test evaluation is changed.

For b) we definitely need to revert, though we usually have some discussoin
of whether to revert or whether we can get a fix quickly enough to tolerate
a non-distributable system (on at least one target) for a few days.

If we are in between a) and b) then a more extensive discussion is required.

Really what is happening here, is not so much that Mark and I are coming
at it from the point of view of being a "boss", but rather from the point
of view of managing a software process.

Yes, it works fine to have a community of developers sharing development
in a relatively uncontrolled manner. That's the way we work internally
at ACT, and really in terms of the development process itself, it makes
very little difference whether we are talking about paid employees of
ACT working on GNAT internally to ACT, or volunteers working on GCC
(some of whom are of course paid to do this work by their respective
companies). We have found that in ACT, we depend on a rather formal
process for people testing their changes (we do not allow changes to
be made, even "trivial, must be correct" changes, without requiring the
complete test suite to be run on at least one target, and preferably
doing a bootstrap as well). Nevertheless we do get some breaks, both
in terms of failing tests, and in terms of failing bootstraps that have
to be addressed.

It is at this point in the software process that some notion of management
must enter in some manner. Someone, or some collective wisdom, must

a) evaluate the situation with builds and testsuite results on all targets

b) determine where the problems are, and as appropriate determine which
patches have caused the problems.

c) figure out what needs to be done to solve the problems. In extreme
and egregious cases, immediate reversion of patches may be necessary,
and someone has to manage this decision process.