-
-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LispUsers submission policy #2011
Comments
What do modern lisp users do? Could we follow quicklisp? ASDF? If we want to replicate the 'original' experience.... during the 1970s Interlisp-10 we would (I would) "fix up" submissions to make them more portable or reliable or callable. I think. Should we categorize the files on to sort out -- which ones have been tested, which ones are there for historical purposes... We could just keep a list of packages and their (CL) packages and their github repository for cloning? |
Back when I ran the process there were two ways of getting something into LispUsers:
1) someone would announce on the info-1100 mailing list that they’d written something that they though other people would appreciate and include the FTP site to download it. I’d download it, confirm it worked, ask if it could be added to LispUsers and add it to the ftp repository.
2) someone would send me a note directly to me saying they had something for LispUsers. Same process, I’d download it, confirm operation, add to the ftp repository and then followup with a note to Info-1100.
There would be the occasional submission that required some specific hardware feature, in which case we’d just have to take it on faith. The whole point was to make it a low-friction process to encourage submissions. Everyone pretty much knew that stuff in LispUsers wasn’t officially supported by vendor support.
… On Feb 4, 2025, at 3:31 PM, Larry Masinter ***@***.***> wrote:
What do modern lisp users do? Could we follow quicklisp? ASDF?
If we want to replicate the 'original' experience.... during the 1970s Interlisp-10 we would (I would) "fix up" submissions to make them more portable or reliable or callable. I think.
Should we categorize the files on to sort out -- which ones have been tested, which ones are there for historical purposes...
We could just keep a list of packages and their (CL) packages and their github repository for cloning?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Back in the day how were the updates of packages from external contributions handled? Were the updates integrated back in LispUsers? |
The author and I would coordinate to get a new version. There was a “submissions” directory on the FTP site that was write-able.
… On Feb 5, 2025, at 6:36 AM, Paolo Amoroso ***@***.***> wrote:
Back in the day how were the updates of packages from external contributions handled? Were the updates integrated back in LispUsers?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
Since I don't expect many submissions in the short to medium term we may continue with the previous process, adapt the LispUsers' rules, and provide additional submission channels. This would reduce friction and overhead for both contributors and us. For example, in addition to sending email contributors may submit a PR or open an issue with attached code and files. I'd add the requirement that submission include documentation that also explains how to install and run a program or, in the case of libraries, provide a few sample calls. This is important for confirming operation and allowing users to run the code. Updates would go through the same process. However, this would work only for infrequently updated packages. For frequently updated code or a large amount of submissions a Quicklisp-like or package database approach would work better. |
As discussed in the February 3, 2025 implementation meeting, this issue is for discussing and defining a submission policy for LispUsers, including aspects such as whether to solicit external contributions.
The text was updated successfully, but these errors were encountered: