emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: burden of maintainance


From: Phillip Lord
Subject: Re: burden of maintainance
Date: Fri, 02 Oct 2015 12:25:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Przemysław Wojnowski <address@hidden> writes:

>> as the burden of maintainance was mentioned: from reading the
>> bug-reports got the impression, a more strict test-regime might reduce
>> that.
>>
>> If a bug shows up, the first question should be: how it could survive
>> the tests?
>
> +1
>
> In previous project I joined a team that couldn't do any release in 4
> years. I've introduced automated tests and refactoring among other
> things and after 2 years we were releasing 4 times a year, with 3 times
> less defects, found much sooner in release cycle and they were easier
> to fix.
>
> Some people here work in academia so maybe don't have such experiences,
> but in software industry automated tests are a standard. Projects
> without (or with weak) tests are replaced with those having strong
> tests.


Well some of us work in academia and still have this experience anyway,
which is why I write tests for most of my own Emacs packages.

WRT Emacs, I think, that testing would be a good thing but there are a
couple of hurdles to overcome. First, most of Emacs doesn't have tests,
simply because it predates widespread use of testing. Secondly, Emacs
use of global state (current-buffer!) can make testing quite difficult;
combined with the reality that some of the functions are pretty large,
and will be difficult to retrofit tests onto, I think this is quite an
issue. And, thirdly, testing of interactive programs is difficult
anyway; the difficulty of writing tests in this environment is much
higher, and the payback lower. 

We can have more than one maintainer. Someone who wanted to just
concentrate on getting a nightly build infrastructure running, with
email to emacs-diffs, and then starting to add fixtures and some other
frameworks to ert would be valuable addition to the process.

Phil



reply via email to

[Prev in Thread] Current Thread [Next in Thread]