Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > Git is not "for users".  It is for developers.
>
> That, unfortunately, is a distinction that doesn't exist with git.

But it exists with the Git repository of Emacs.

> I have many students with no detectable neural activity as far as
> software development goes keeping their theses in a group-accessible
> git repo.  That means I don't have to fish their content out of some
> broken mail message, and it keeps a record of when they are actually
> working on their documents.  (If I could only get them to use Emacsen
> and TeX so git diff would be useful!  But that's another story.)  Some
> of them have actually discovered that the log is useful to them too!

So they are using it as a developer repo.  They are not using it as an
archival system for generated files, and indeed Git very explicitly is
not an archival system.  The discussion to preserve file modification
dates was there in its beginnings, and Git does not preserve them (and
does not offer ways to preserve them) on purpose.

> True, from the developer's POV, git is not a great way to distribute
> products-with-source because it doesn't keep Make relationships up to
> date.  However, that doesn't mean it doesn't make a good way to
> distribute product to users.

Emacs' tarball is not a finished product.  It needs to have some
relations intact to maintain pregenerated info files and stuff.

> Perhaps this tension could be addressed by having a "developer" branch
> (which could be trunk = "master", of course) which assumes a complete
> suite of tools for developers, and a "distribute" branch containing
> products that require tools other than Emacs itself for users.

Doesn't work since Git does not preserve file dates on checkout.

> Thinking out loud, using the current "maintenance" branch as a
> "distribute" branch might even work.  With appropriate tools (to be
> written AFAIK, unfortunately), you can recover (to a close
> approximation) the necessary timestamp information to avoid
> unnecessary rebuilding by Make, too.

The tool is written already, of course.  Make has some flag for touching
everything instead of building it.  But that would include non-version
controlled binaries in the tree that have not been touched on the last
checkout.

-- 
David Kastrup