From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: burden of maintainance Date: Fri, 02 Oct 2015 17:15:46 +0300 Message-ID: <83r3ld5pbh.fsf@gnu.org> References: <560CEA6A.9000907@online.de> <834miaa847.fsf@gnu.org> <560D7F77.8060507@online.de> <83lhbm8kye.fsf@gnu.org> <560E8C80.5040007@cumego.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1443800217 12599 80.91.229.3 (2 Oct 2015 15:36:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 2 Oct 2015 15:36:57 +0000 (UTC) Cc: andreas.roehler@online.de, emacs-devel@gnu.org To: =?utf-8?Q?Przemys=C5=82aw?= Wojnowski Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 02 17:36:48 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zi2O6-0003O2-Vp for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 17:36:47 +0200 Original-Received: from localhost ([::1]:60885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi2O6-0005tK-9c for ged-emacs-devel@m.gmane.org; Fri, 02 Oct 2015 11:36:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi17w-0007rB-GQ for emacs-devel@gnu.org; Fri, 02 Oct 2015 10:16:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zi17s-0000bz-9M for emacs-devel@gnu.org; Fri, 02 Oct 2015 10:16:00 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:44861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zi17r-0000bW-SP for emacs-devel@gnu.org; Fri, 02 Oct 2015 10:15:56 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NVL00G00IZEO200@mtaout27.012.net.il> for emacs-devel@gnu.org; Fri, 02 Oct 2015 17:12:06 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVL00AQPJG6LM50@mtaout27.012.net.il>; Fri, 02 Oct 2015 17:12:06 +0300 (IDT) In-reply-to: <560E8C80.5040007@cumego.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.183 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190700 Archived-At: > Cc: emacs-devel@gnu.org > From: Przemys=C5=82aw Wojnowski > Date: Fri, 2 Oct 2015 15:54:08 +0200 >=20 > >>> Suggestions for how to improve our test suite without alienatin= g > >>> potential contributors are welcome. > I would say that without tests they are alienated. It's much harder= to=20 > contribute anything without test coverage. That's a misunderstanding. I explained what I meant in a later message. > >> What about saying: no checkin before the tests passed? > > > > That is OK, but what to do if some tests fail for many moons bef= ore > > they are fixed? We cannot stop development because of that. >=20 > 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). >=20 > I've seen that "procedure" in many projects and it worked fine. Me too. But we are not talking about theoretical feasibility. > Of course it is not welded and can be customized to suite Emacs > development. I'm okay with that, if everyone agrees. You should know, though, tha= t Emacs development up until now is VERY different from such projects: we have no strictly codified process for committing and patch reviews= , never had one. Introducing such mandatory procedures is a big change= . > > 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, bu= t > many things can. We are mis-communicating again: I meant features which display something or involve interactive keyboard input. > a good start would be to add a C testing library and enabling it in > tests. I agree. I hope someone will volunteer to make this happen.