Skip to content
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

Open
pamoroso opened this issue Feb 4, 2025 · 5 comments
Open

LispUsers submission policy #2011

pamoroso opened this issue Feb 4, 2025 · 5 comments

Comments

@pamoroso
Copy link
Contributor

pamoroso commented Feb 4, 2025

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.

@masinter
Copy link
Member

masinter commented Feb 4, 2025

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?

@Anzus
Copy link
Contributor

Anzus commented Feb 4, 2025 via email

@pamoroso
Copy link
Contributor Author

pamoroso commented Feb 5, 2025

Back in the day how were the updates of packages from external contributions handled? Were the updates integrated back in LispUsers?

@Anzus
Copy link
Contributor

Anzus commented Feb 5, 2025 via email

@pamoroso
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants