Stale undo-tree in elpa

Stale undo-tree in elpa

[Kelly Dean]

The current content of http://elpa.gnu.org/packages/archive-contents (with sha1 d21c91d0..), with Last-Modified header showing Dec 28, 2014, says that undo-tree 0.6.5 is current.
The content of http://elpa.gnu.org/packages/undo-tree-0.6.5.el (with sha1 58e720d1..) includes the line
Repository: http://www.dr-qubit.org/git/undo-tree.git
and is based on commit ffb346ac.. at that repo, which is dated Nov 19, 2013.
However, commit a3e81b68.. is the latest, and is dated May 9, 2014.
Emacs 24.4 was released Oct 20, 2014, and the first pretest was Apr 12. The most recent undo-tree prior to that pretest was commit b35a6af8.. on Jan 10, 2014, so the package was already stale in elpa even for the pretest.

It appears the FSF doesn't automatically pull, and instead either manually pulls or relies on package maintainers to push, but people are busy with other things.

For packages such as undo-tree that have only a trunk, not separate devel and stable branches, the assumption must be that new versions are unstable unless declared otherwise. But the FSF could motivate maintainers to use separate devel and stable branches by auto-pulling daily from stable into elpa; then nobody has to bother with push or with manual pull, and elpa's packages don't become stale.

Of course, package maintainers would need to sign their commits to stable, and the auto-puller would need to reject unsigned commits. If the FSF is concerned about maintainers going bad and wants the chance to review before accepting new versions into elpa, then just stage auto-pulled updates for a week before auto-updating elpa, which gives the FSF a chance to veto, but avoids pocket veto.

For undo-tree in particular, the maintainer might as well mark its trunk as the stable branch suitable for auto-pull, because he already ensures that each new commit is stable.

Re: Stale undo-tree in elpa

[Stefan Monnier]

> It appears the FSF doesn't automatically pull,

[ FWIW, the FSF doesn't have much to do with this, other than providing
  the hardware resources to host elpa.gnu.org, and holding the copyright
  for the code. ]

No, indeed elpa.git is not auto-updated by pulling from some remote
repository.  Instead it's the package maintainer's responsibility to
keep his elpa.git code uptodate.  I did consider auto-pulling, but for
now I decided it's better not to: it's better to have a human take
responsibility for installing code into elpa.gnu.org.

Note that pulling can't be made 100% automatic since there can be conflicts.

> and instead either manually pulls or relies on package maintainers to
> push, but people are busy with other things.

An easy way to avoid those problems and save time is to use elpa.git as
the upstream on which all work is done.  That's the recommended way to
use elpa.git.

> For packages such as undo-tree that have only a trunk, not separate devel
> and stable branches, the assumption must be that new versions are unstable
> unless declared otherwise.

Stability of the code is largely irrelevant since new packages are only
created from elpa.git when the "Version:" header of the package is modified.
Furthermore, releasing a broken package is not a big deal either since
releasing a fix is quick&easy.


        Stefan

Re: Stale undo-tree in elpa

[Kelly Dean]

Dmitry Gutov wrote:
>Maybe we should ask the author to update, but to be fair, there are no
>important functional changes between 0.6.5 and 0.6.6.

I used undo-tree as an example, but the main point of my message was that authors shouldn't have to do a separate update step. Anyway, Stefan responded that authors who don't want to do a separate update step can just use elpa directly for their repositories.