This is probably a good time for me to pop this question which I have had for a while: Don't we have a formal unit-test/review cycle around the commits we make into the code base? Also do we have any test suites around major packages that can quickly sanitize our checkins? Or an automated build and test system?
Groff seems to be complex enough for not just one person to get their heads around, thus complex enough that one might break something somewhere inadvertently? We certainly seem to have enough code flux to warrant such infrastructure. Also, if we have a solid process around, new developers (like me) will be less apprehensive of making code changes! Have we investigated this in the past? - Vaibhaw On Sun, Jun 22, 2014 at 9:24 AM, Werner LEMBERG <w...@gnu.org> wrote: > > >> It is certainly nice to see when upstream groff development makes > >> progress. However, i would consider it common practice for > >> upstream committers to test the build before committing, rather > >> than relying on downstream consumers to catch trivial build system > >> bugs... > > > > Ingo's right. We need to stick to the policy of posting changes > > that affect the build system and the core distribution prior to > > committing. > > It's good that we have a watchdog called Ingo :-) Peter, please apply > his trivial patch. > > > Werner > >