emacs-devel
[Top][All Lists]
Advanced

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

Re: Next release from master


From: Óscar Fuentes
Subject: Re: Next release from master
Date: Wed, 10 Feb 2016 04:24:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Kaushal Modi <address@hidden> writes:

> On Tue, Feb 9, 2016 at 7:38 PM, Óscar Fuentes <address@hidden> wrote:
>
>> What does "to be tested" mean here? Does it mean that the feature was
>> not thoroughly tested by the developer yet?
>>
>
> I use the dev builds of emacs as my daily driver. I keep the emacs-25 and
> master builds ready at all times. For now, I am using emacs-25 as my daily
> driver, mainly to test it thoroughly before its public release. But if some
> bug creeps in that thwarts my day-job work, then I can report that and
> switch to using the master branch build till the bug gets fixed (this is
> just an example, I haven't needed to do that yet).

I'm using emacs-dev since many years ago. Given its complexity, it is
one of the most stable and reliable software packages I use. However,
throwing half-working, untested, intrusive changes into master would
change that for sure. For most part of the last year I was forced to use
an old build of emacs-dev because someone changed a package which I
depend on without a cursory testing. When the problem was reported,
there was no positive response from the developer. It was not practical
to revert the change because it was tangled with other unrelated changes
across multiple packages. The problem stayed for months until somebody
else who is familiar with the code fixed it enough to be usable again.
In the meantime, emacs-dev had at least one less tester.

This is a problem typical of projects who use the main branch as a
sandbox.

What keeps voluntary-based projects going is social conventions. Not
stepping onto anybody else's toes is one of the most basic of them. That
is helped by developing features in branches until one is honestly
convinced that merging will not introduce known or suspected problems
that harm other's work, and be quick to revert if some serious
inconvenience cannot be fixed right away (which is facilitated by having
a merge commit instead of multiple commits mixed with the rest of the VC
history.)

[snip]




reply via email to

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