[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
Re: burden of maintainance, Eli Zaretskii, 2015/10/08