unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Przemysław Wojnowski" <esperanto@cumego.com>
To: "Eli Zaretskii" <eliz@gnu.org>,
	"Andreas Röhler" <andreas.roehler@online.de>
Cc: emacs-devel@gnu.org
Subject: Re: burden of maintainance
Date: Fri, 2 Oct 2015 15:54:08 +0200	[thread overview]
Message-ID: <560E8C80.5040007@cumego.com> (raw)
In-Reply-To: <83lhbm8kye.fsf@gnu.org>

>>> Suggestions for how to improve our test suite without alienating
>>> potential contributors are welcome.
I would say that without tests they are alienated. It's much harder to 
contribute anything without test coverage.

>> What about saying: no checkin before the tests passed?
 >
 > That is OK, but what to do if some tests fail for many moons before
 > they are fixed?  We cannot stop development because of that.

Everyone should run tests before push.
Even though they sometimes fail for various reasons (someone forgot,
different env). In such case the person is notified and should fix that
before doing any other work. Usually if it cannot be done within a few
hours (a day) the commit is reverted or test marked as ignored
(sometimes it's a faulty test).

I've seen that "procedure" in many projects and it worked fine.
Of course it is not welded and can be customized to suite Emacs
development.

 > Worse, for interactive features (and there are a lot of them),
> we lack the infrastructure for writing automated tests.
Can you give an example? Of course not everything can be tested, but
many things can.

IMHO it's a matter of restructuring the code. If interactive functions
try to do work by themselves then it is hard, but if they only take
input and pass to another component (for example like in MVC pattern)
then it's much easier.

> Also, I don't
> quite see who will write tests for large portions of the C code, given
> how few people are even prepared to work on that.  The result is that
> getting closer to good coverage is a huge job.
Everything starts somewhere and a good start would be to add a C
testing library and enabling it in tests.

This would at least enable those willing to write tests. Currently they
can't, even if they would like to.



  parent reply	other threads:[~2015-10-02 13:54 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01  8:10 burden of maintainance Andreas Röhler
2015-10-01 16:03 ` Eli Zaretskii
2015-10-01 18:46   ` Andreas Röhler
2015-10-01 19:09     ` Eli Zaretskii
2015-10-01 20:18       ` Andreas Röhler
2015-10-01 20:27         ` Eli Zaretskii
2015-10-02 13:54       ` Przemysław Wojnowski [this message]
2015-10-02 14:15         ` Eli Zaretskii
2015-10-02 17:18           ` Tassilo Horn
2015-10-02 18:24             ` Eli Zaretskii
2015-10-02 18:47               ` joakim
2015-10-02 19:16               ` Tassilo Horn
2015-10-02 20:53                 ` Eli Zaretskii
2015-10-02 19:28               ` Chad Brown
2015-10-02  7:51   ` Helmut Eller
2015-10-02  8:47     ` Eli Zaretskii
2015-10-02  8:56       ` Helmut Eller
2015-10-02  8:59         ` Eli Zaretskii
2015-10-02 11:46         ` Michael Albinus
2015-10-02 11:58   ` Phillip Lord
2015-10-02 13:14     ` Artur Malabarba
2015-10-02 13:36     ` Eli Zaretskii
2015-10-02 15:00       ` Andreas Röhler
2015-10-02 15:16         ` Eli Zaretskii
2015-10-02 17:19           ` Andreas Röhler
2015-10-02 18:08             ` Eli Zaretskii
2015-10-02 18:54               ` Andreas Röhler
2015-10-02 20:39                 ` Tassilo Horn
2015-10-03  6:53                   ` Andreas Röhler
2015-10-03  7:31                     ` Tassilo Horn
2015-10-03  1:38             ` Richard Stallman
2015-10-03  0:38       ` Eric Ludlam
2015-10-02 23:24     ` Xue Fuqiao
2015-10-03  6:42       ` Przemysław Wojnowski
2015-10-03  7:00         ` Xue Fuqiao
2015-10-03  7:15         ` Eli Zaretskii
2015-10-01 16:34 ` Przemysław Wojnowski
2015-10-02 11:25   ` Phillip Lord
2015-10-02 12:27     ` Michael Albinus
2015-10-02 14:53       ` Phillip Lord
2015-10-02 16:56         ` Michael Albinus
2015-10-03  1:35     ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560E8C80.5040007@cumego.com \
    --to=esperanto@cumego.com \
    --cc=andreas.roehler@online.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).