On Fri, 19 Jul 2019 22:15:42 +0200 Daniel Kochmański wrote:
> thank you for your contribution. We do not accept patches over mailing
> list. Instead we prefer merge requests on our repository.
So
If you want your code in Embeddable Common-Lisp project, please
send a patch to mailing list with additional tag [PATCH] in
subject.
which appears in common-lisp.net/project/ecl/static/quarterly/ecl-quarterly.org
is no longer valid ? I don't recall this being mentioned on the mailing list.
> This makes
> possible peer review, requeesting changes and continous integration.
>
> Repository is located here:
> https://gitlab.com/embeddable-common-lisp/ecl
>
> Please create a git commit with detailed commit message and make a merge
> request there. Branch used for development is called "develop" (it will
> be cloned as default unless you specify it otherwise).
>
> If you are not familiar with gitlab workflow here's how it goes:
> - [on gitlab] create an account on the platform
> - [on gitlab] fork the repository into your personal userspace
> - [locally] clone the repository from your fork
> - [locally] do appriate changes on your computer and make git commit
> - [locally] push to your local repository
> - [on gitlab] go to merge requests tab and select "new merge request"
Unfortunately gitlab.com gives at present an SSL error with all my browsers
so I would have to move to a newer version of Linux before I'm able to access
it and it will be a while before I get around to that. I note that I can
access gitlab.common-lisp.net .I'm mentioning this because ecl-quarterly.org
says
After 15.3.7 release there are a few changes going on. We are now
hosted at gitlab.com (however it would be nice to move to
gitlab.common-lisp.net, just /not now/),
> While this patch is small and I could manage merging it (although it is
> made against ecl 16.1.3 version, so patch may fail against develop
> branch), I'm anxious about setting a precedence - working with patches
> manually is more time-consuming on my part. I hope that this explanation
> is sufficient to you.
Yes , I understand. In any case it turns out that the mailing list mangled
the code. At 2 places when my patch has ",@forms" , that is a comma followed
by the at sign followed by "forms" , the list shows this as ", at forms" .
This is probably a bug with the list software. I'm sending this message
BASE64 encoded so we'll see if the comma-at sequence suffers the same
transformation.
