emacs-devel
[Top][All Lists]
Advanced

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

Stale undo-tree in elpa


From: Kelly Dean
Subject: Stale undo-tree in elpa
Date: Tue, 30 Dec 2014 10:01:48 +0000

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.



reply via email to

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