emacs-devel
[Top][All Lists]
Advanced

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

Re: burden of maintainance


From: Eli Zaretskii
Subject: Re: burden of maintainance
Date: Fri, 02 Oct 2015 17:15:46 +0300

> Cc: address@hidden
> From: Przemysław Wojnowski <address@hidden>
> Date: Fri, 2 Oct 2015 15:54:08 +0200
> 
> >>> 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.

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 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.

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, that
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, but
> 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.




reply via email to

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