Request for policy ruling - dropping Arch support fom VC?

Request for policy ruling - dropping Arch support fom VC?

[Eric S. Raymond]

I don't know what the project policy is on supporting modes for software that
has been end-of-lifed.  Now I need to know.

Michael Albinus has been working on a test framework for VC.  In the
process, we've discovered that the Arch register method is busted.
I'm pretty sure I didn't do this with my recent changes to VC, that
the arch backend had bitrotted due to changes in Arch.

Arch has been end-of-lifed by its author.  I think I have better
things to do than chase a backward-compatibility problem in a mode for
a VCS that (unlike RCS or SCCS) probably hasn't seen live use in a
decade. Therefore I'd like to solve this problem the simple way, by
dropping Arch support.

What is policy on this sort of thing?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The right of the citizens to keep and bear arms has justly been considered as
the palladium of the liberties of a republic; since it offers a strong moral
check against usurpation and arbitrary power of rulers; and will generally,
even if these are successful in the first instance, enable the people to resist
and triumph over them."
        -- Supreme Court Justice Joseph Story of the John Marshall Court

Re: Request for policy ruling - dropping Arch support fom VC?

[Paul Eggert]

Eric S. Raymond wrote:
> What is policy on this sort of thing?

A good rule of thumb is that if external software is no longer supported by its 
own community, then Emacs needn't worry about it.  That's why Emacs dropped 
support for IRIX, for example -- SGI retired IRIX about a year ago.  So if Arch 
has been retired, we can remove support for it from Emacs.

Re: Request for policy ruling - dropping Arch support fom VC?

[Stefan Monnier]

> I don't know what the project policy is on supporting modes for
> software that has been end-of-lifed.  Now I need to know.

As usual the answer is "it depends".  I was planning to move vc-arch.el
to the lisp/obsolete subdirectory, but as for dropping support outright,
I'm not completely sure because I don't know if some project might still be
using Arch or not.

> Michael Albinus has been working on a test framework for VC.  In the
> process, we've discovered that the Arch register method is busted.
> I'm pretty sure I didn't do this with my recent changes to VC, that
> the arch backend had bitrotted due to changes in Arch.

It should be pretty easy to check if Emacs-24.4's vc-arch.el works right.

I suggest to keep vc-arch.el on life-support with minimal efforts: only
update the code "in the obvious way", just so that if someone were to
come and complain that Arch doesn't work any more, it should be
reasonably easy to fix it.


        Stefan

Re: Request for policy ruling - dropping Arch support fom VC?

[Eric S. Raymond]

Stefan Monnier <monnier@iro.umontreal.ca>:
> It should be pretty easy to check if Emacs-24.4's vc-arch.el works right.

Not as easy as you might think.  Ubuntu doesn't package Arch, which is
a pretty good clue that nobody has cared about it for quite a while.
The last source snapshot was made nine years ago. I downloaded it and looked;
the build insteructions are rudimentary and not reassuring.

Here's the entire diff since I started reworking VC.  There are no
logic changes, only only one change touches the register method, and
that just removes an unused argument.

diff --git a/lisp/vc/vc-arch.el b/lisp/vc/vc-arch.el
index 53b8e35..d1344f2 100644
--- a/lisp/vc/vc-arch.el
+++ b/lisp/vc/vc-arch.el
@@ -231,8 +231,7 @@ Only the value `maybe' can be trusted :-(."
   "Return the administrative directory of FILE."
   (expand-file-name "{arch}" (vc-arch-root file)))
 
-(defun vc-arch-register (files &optional rev _comment)
-  (if rev (error "Explicit initial revision not supported for Arch"))
+(defun vc-arch-register (files &optional _comment)
   (dolist (file files)
     (let ((tagmet (vc-arch-tagging-method file)))
       (if (and (memq tagmet '(tagline implicit)) comment-start)
@@ -262,10 +261,6 @@ Only the value `maybe' can be trusted :-(."
 	       ;; Strip the terminating newline.
 	       (buffer-substring (point-min) (1- (point-max)))))))))
 
-(defun vc-arch-workfile-unchanged-p (_file)
-  "Stub: arch workfiles are always considered to be in a changed state,"
-  nil)
-
 (defun vc-arch-state (file)
   ;; There's no checkout operation and merging is not done from VC
   ;; so the only operation that's state dependent that VC supports is commit
@@ -315,10 +310,11 @@ Only the value `maybe' can be trusted :-(."
 		    'up-to-date
 		  'edited)))))))))
 
-;; -dir-status called from vc-dir, which loads vc, which loads vc-dispatcher.
+;; dir-status-files called from vc-dir, which loads vc,
+;; which loads vc-dispatcher.
 (declare-function vc-exec-after "vc-dispatcher" (code))
 
-(defun vc-arch-dir-status (dir callback)
+(defun vc-arch-dir-status-files (dir _files callback)
   "Run 'tla inventory' for DIR and pass results to CALLBACK.
 CALLBACK expects (ENTRIES &optional MORE-TO-COME); see
 `vc-dir-refresh'."
@@ -452,7 +448,7 @@ CALLBACK expects (ENTRIES &optional MORE-TO-COME); see
     (vc-arch-command nil 0 files "commit" "-s" summary "-L" comment "--"
 		     (vc-switches 'Arch 'checkin))))
 
-(defun vc-arch-diff (files &optional oldvers newvers buffer)
+(defun vc-arch-diff (files &optional async oldvers newvers buffer)
   "Get a difference report using Arch between two versions of FILES."
   ;; FIXME: This implementation only works for singleton filesets.  To make
   ;; it work for more cases, we have to either call `file-diffs' manually on
@@ -469,7 +465,6 @@ CALLBACK expects (ENTRIES &optional MORE-TO-COME); see
     (if newvers
         (error "Diffing specific revisions not implemented")
       (let* (process-file-side-effects
-	     (async (not vc-disable-async-diff))
              ;; Run the command from the root dir.
              (default-directory (vc-arch-root file))
              (status
@@ -496,8 +491,6 @@ CALLBACK expects (ENTRIES &optional MORE-TO-COME); see
   "A wrapper around `vc-do-command' for use in vc-arch.el."
   (apply 'vc-do-command (or buffer "*vc*") okstatus vc-arch-program file flags))
 
-(defun vc-arch-init-revision () nil)
-
 ;;; Completion of versions and revisions.
 
 (defun vc-arch--version-completion-table (root string)

> I suggest to keep vc-arch.el on life-support with minimal efforts: only
> update the code "in the obvious way", just so that if someone were to
> come and complain that Arch doesn't work any more, it should be
> reasonably easy to fix it.

That's doable.  I think I've finished making incompatible API changes,
so we can put this code on ice knowing that fixing it (if we ever have
to) will be pretty trivial.

Let's do what you were considering and move the arch back end to the
obsolete directory, also taking Arch out of the supported-backends list.
That way the VC test code won't trip over it, but it will be handy if
someone shows up wanting Arch support.  
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Request for policy ruling - dropping Arch support fom VC?

[Ulrich Mueller]

>>>>> On Sat, 6 Dec 2014, Eric S Raymond wrote:

> Ubuntu doesn't package Arch, which is a pretty good clue that nobody
> has cared about it for quite a while. The last source snapshot was
> made nine years ago. I downloaded it and looked; the build
> insteructions are rudimentary and not reassuring.

Huh? For tla-1.3.5, the build process simply consists of (out-of-tree)
"configure" and "make".

Gentoo removed the package from the main repository in 2008, but we
still have an ebuild for it in the sunrise overlay.

Ulrich

Re: Request for policy ruling - dropping Arch support fom VC?

[Eric S. Raymond]

Ulrich Mueller <ulm@gentoo.org>:
> Huh? For tla-1.3.5, the build process simply consists of (out-of-tree)
> "configure" and "make".

In the top-level directory or src?  It wasn't clear.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Request for policy ruling - dropping Arch support fom VC?

[Ulrich Mueller]

>>>>> On Sat, 6 Dec 2014, Eric S Raymond wrote:

>> Huh? For tla-1.3.5, the build process simply consists of
>> (out-of-tree) "configure" and "make".

> In the top-level directory or src?  It wasn't clear.

In src. The Gentoo ebuild basically does the following:

   mkdir src/=build
   cd src/=build
   ../configure
   make

Re: Request for policy ruling - dropping Arch support fom VC?

[Eric S. Raymond]

Ulrich Mueller <ulm@gentoo.org>:
> >>>>> On Sat, 6 Dec 2014, Eric S Raymond wrote:
> 
> >> Huh? For tla-1.3.5, the build process simply consists of
> >> (out-of-tree) "configure" and "make".
> 
> > In the top-level directory or src?  It wasn't clear.
> 
> In src. The Gentoo ebuild basically does the following:
> 
>    mkdir src/=build
>    cd src/=build
>    ../configure
>    make

OK, I'll try that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Request for policy ruling - dropping Arch support fom VC?

[Stefan Monnier]

>> It should be pretty easy to check if Emacs-24.4's vc-arch.el works right.
> Not as easy as you might think.  Ubuntu doesn't package Arch, which is
> a pretty good clue that nobody has cared about it for quite a while.

It's still in Debian.

> The last source snapshot was made nine years ago. I downloaded it and looked;

I know, but AFAIK "it just works" and has *very* few dependencies, so
it never needed new releases to adapt to new versions of its dependencies.

In any case it's not terribly important to do tests, I was suggesting
doing it if you want to figure out when things broke, assuming
installing tla was easy (which it is under Debian, even on armhf).

> That's doable.  I think I've finished making incompatible API changes,
> so we can put this code on ice knowing that fixing it (if we ever have
> to) will be pretty trivial.

Great.

> Let's do what you were considering and move the arch back end to the
> obsolete directory, also taking Arch out of the supported-backends list.
> That way the VC test code won't trip over it, but it will be handy if
> someone shows up wanting Arch support.  

Fine,


        Stefan