Re: Feature freeze and Tramp?

[David Kastrup <dak@gnu.org>]

Kai Grossjohann <kai@emptydomain.de> writes:

> I'm not sure what I should do about Tramp given the feature freeze.  I
> would like to merge 2.0.40 with Emacs, but it is not purely a bugfix
> release: 2.0.39 contained half of the functionality needed for
> password caching (it has the password cache), 2.0.40 supplies the
> other half (it /uses/ the password cache).
> 
> There is now a stable branch in the Tramp repository so that it is
> easier to make sure that future revisions in the 2.0 series are
> bugfix-only.
> 
> What should I do?

In a stable release, there really is no place for half-implemented
stuff.  Either one should rewind to the state before the
half-implementation, backing it out modulo bug-fixes, or one should
complete it.  Considering the additional work of maintaining a
separate back-ported branch that would have to be created separately,
and considering the relative youth of the feature freeze and the
number of things that have just gotten in, I'd say in this case put it
in and maintain the stable branch from this point on.  Considering
your narrow focus, it is highly unlikely that problems with Tramp
2.0.40 will slow down the proper release in any manner.

The purpose of the feature freeze is to concentrate on getting work
done and finished, not on starting new work in the form of backports.
Unless this appears necessary for getting the release out.  I think
that the additional work of backports will mostly be warranteed close
to the finishing line.

Half-finished stuff should get finished or taken out.  Unless this
affects stability, I'd opt for putting it in in this case.  If it
turns out that this has been the wrong choice, we can still back it
out again.

The same holds for other stuff: if it turns out that we have no way to
get them stable in reasonable time, there will be a point of time when
we rather take them out than try to fix them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum