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.