On Fri, 1 Jun 2012, Richard Fateman wrote:
> > (1) I want to rely on the author's authority in the field to be able to
> > assume the code is right.
> or the reverse: knowing that the author is perhaps not known for
> checking his/her code carefully. or knowing that the author is
> distinctly lacking in authority (e.g. changes made by a high school
> student who thinks he/she knows calculus "better".)
That is why the only one who can commit patches are the maintainers,
who are supposed to review the patches before they commit them. Once
the patch is reviewed and checked by tests, it does not matter who
wrote it.
By the way, git supports the separation between the one who wrote the
change and the one who applied it.
> I'm not sure what you are saying, but if there was an act of
> authorship involved, I think the author should take responsibility,
> meaning both the claim and blame.
I hope you have seen WARRANTY section in COPYING file :-)
> A version control system is important when there are many workers
> potentially altering the same code at about the same time. It makes
> sense when the natural division of code is a file.
>
> For Maxima, I suspect that there are rarely people simultaneously
> modifying the same file; checking out/in files is potentially
> useful.
>
> However, the natural division of code in Maxima and Lisp is a
> definition (defun .. ..) or some other similar expression like
> defvar, defmacro defmfun defprop.
>
> Checking files in and out is therefore a poor fit.
Version control is not about check-in and check-out since CVS, that is
more than 20 years already.
> There is a history of "environmental" development systems esp. for
> Lisp, as used in interlisp or bbn-lisp. This mode of operation, in
> which a system is incrementally defined interactively, edited and
> tested WITHOUT LEAVING LISP. It has not prevailed in the market, but
> the model that has prevailed, namely source-code-control-edit /
> compile/ load /make-dump/ debug/ ... is clumsy.
Once you have applied a patch you are not required to re-make -- just
reload the changed function or file.
> It would be totally unacceptable except for the fact that computers are so
> damned fast that it doesn't take long to recompile fairly large code
> collections.
Right: re-making for a change in a single lisp file takes
only 10 seconds; the whole build is just a minute.
--
Regards,
ASK