> Lately, we are seing a considerable number of large commits
> shuffling stuff around that are inherently hard to review. [...]
Actually, I've never reviewed Bernd's stuff in greater detail... The
main reason was always lack of time. But the same was true for the
mom package and gropdf, for example: My policy was to consider those
parts of groff as `sub-projects', and the respective authors had full
responsibility for their code.
> At the same time, we are seing that a large fraction of commits
> contains blatant issues, so they were apparently insufficiently
> tested before commit. Some of these issues are fixed shortly
> afterwards (anybody remember the commit exchanging the arguments of
> Perl push()?). But what about those that aren't? Or what makes you
> think that no subtle issues are being introduced, at a rate of the
> same order of magnitude as the obvious, blatant issues we are all
> seeing?
I agree that this kind of workflow is not optimal, but on the other
hand: It's OK with me, as long as the issues are related to the
subprojects. Folks, be happy that there are guys who are actually
working!
> What we should really worry about is the integrity of groff code at
> places where malfunction is less obvious.
Certainly. It essentially means to review all changes except Bernd's,
Peter's and Deri's subprojects :-)
> However, no kind of unit testing or even automated integration
> testing can replace careful development practices and careful manual
> testing.
Indeed.
Werner
