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

Please add quicklisp-project-submission #980

Closed
guicho271828 opened this issue Aug 12, 2015 · 14 comments
Closed

Please add quicklisp-project-submission #980

guicho271828 opened this issue Aug 12, 2015 · 14 comments

Comments

@guicho271828
Copy link
Contributor

Please add quicklisp-project-submission , available at https://github.com/guicho271828/quicklisp-project-submission.git.

Description: Submit a local git repository to github, then make an issue @ github.com/quicklisp/quicklisp-projects/issues

License: LLGPL

Submitted using quicklisp-project-submission.

Real human comments: /This is a very live example of using this library. Thanks!/

@bhyde
Copy link

bhyde commented Aug 12, 2015

Interesting, not a bad idea. But...

I’d be reluctant to encourage submiting a new project immediately after it was first deposited in a public
repo. A bit of time to let things settle and test it seems like good practice worth encouraging.

Also, seems a shame to presume github and git.

All that said. … It would be awesome to have something along these lines:

(ql:quick-load “quicklisp-project-critique”)
(ql-critique ‘my-awesome-project :extra-helpful t :silence ‘(q14))
Q25 Missing description.
Q12 License seems unusual, if that was intentional set try :unusual-licence t.
C73 Cool, this system is is already in quicklisp.
S12 Check if similar tools already exist.
S17 Consider building the package on mulitple implementations.
C08 Readme.org seems very short.

Note how the extra-helpful flag licenses it to make suggestions it can’t
check with code.

Writing the submission note and opening the email can be it’s own function.
That needs the URL for the repo, but heuristically discovering the URL for
the repo can build out over time.

  • ben

On Aug 12, 2015, at 5:49 AM, Masataro Asai notifications@github.com wrote:

Please add quicklisp-project-submission , available at https://github.com/guicho271828/quicklisp-project-submission.git https://github.com/guicho271828/quicklisp-project-submission.git.

Description: Submit a local git repository to github, then make an issue @ github.com/quicklisp/quicklisp-projects/issues

License: LLGPL

Submitted using quicklisp-project-submission.

Real human comments: /This is a very live example of using this library. Thanks!/


Reply to this email directly or view it on GitHub #980.

@quicklisp
Copy link
Owner

I like this idea very much, but I don't like the name. To me, it seems like naming it "quicklisp-something-something" suggests it is part of quicklisp itself, rather than an add-on. Is there perhaps another name, or another configuration of the name, that you could use?

I like Ben's ideas too. I think an initial version of a project that submits projects should at least check for metadata (:license, :author, :description) in the systems and for the presence of a README.

@guicho271828
Copy link
Contributor Author

Thanks for the review, anyway I'm happy to hear that you both like this idea! Overall, this is a first try and is not a usual "please add " kind.

This project is inspired by Julia's packaging system which basically do the similar things. (seemingly called "publishing", but I'm no julia expert.) http://julia.readthedocs.org/en/latest/manual/packages/

re: other VC --- I agree, it currently only targets git and github, but that would be fixed if non-github users want to port it to hg or other VC.

re: immediately uploading --- um, is that a comment on this library itself (yes this is done in 4 hrs), or on the future possibility of other junk libraries?

re: name ---- Also, yes, "quicklisp" prefix does sound too official. I welcome any better names if there's any idea. I have no good idea currently, though. Or it should be rather really a part of quicklisp itself and not one of libraries (after some more maturity).

@bhyde
Copy link

bhyde commented Aug 12, 2015

Oh sorry. I didn’t intend to suggest that you were moving too fast.

I was intended to say I thought it was questionable encouraging people to merge publishing to github at the same instant they ask Zach to add it to Quicklisp. But maybe that’s because I tend add to Quicklisp only a tiny portion of the packages I make public on github.

It’s one of life’s mysteries that people should move with care and deliberation; but individuals should move more quickly. :)

  • ben

On Aug 12, 2015, at 10:41 AM, Masataro Asai notifications@github.com wrote:

Thanks for the review, anyway I'm happy to hear that you both like this idea! Overall, this is a first try and is not a usual "please add " kind.

This project is inspired by Julia's packaging system which basically do the similar things. (seemingly called "publishing", but I'm no julia expert.) http://julia.readthedocs.org/en/latest/manual/packages/ http://julia.readthedocs.org/en/latest/manual/packages/
re: other VC --- I agree, it currently only targets git and github, but that would be fixed if non-github users want to port it to hg or other VC.

re: immediately uploading --- um, is that a comment on this library itself (yes this is done in 4 hrs), or on the future possibility of other junk libraries?

re: name ---- Also, yes, "quicklisp" prefix does sound too official. I welcome any better names if there's any idea. I have no good idea currently, though. Or it should be rather really a part of quicklisp itself and not one of libraries (after some more maturity).


Reply to this email directly or view it on GitHub #980 (comment).

@Hexstream
Copy link
Contributor

I like this project idea!

@quicklisp I understand that "quicklisp-slime-helper" is "first-party" (made by you), but isn't it still considered an "add-on"? Couldn't it technically have been independently written and submitted by a third-party?

While there is currently only one project in quicklisp with "quicklisp" in its name (I think) and it just happens to be first-party, you have previously stated that you very much like people building tools on top of quicklisp, and I'm not sure how much actual "brand confusion" there is to avoid in disallowing third-party projects with "quicklisp" in their name, especially as the "quicklisp in its name always means first-party" association would fade out over time as more such third-party projects are added.

I would certainly understand if you had a certain reluctance to establish a policy where any random projects of varying quality are entitled to use "quicklisp" as part of their name if they feel like it.

I don't have a strong opinion on this, and I completely defer to your judgment on this particular matter. I'm just throwing this out there.

@creichert
Copy link

I’d be reluctant to encourage submiting a new project immediately after it was first deposited in a public repo. A bit of time to let things settle and test it seems like good practice worth encouraging.

@bhyde You don't have to encourage it, but there is absolutely nothing wrong with it.

As for the naming, I think the submission process should be as open as possible. Other language communities flourish without imposing restrictions. For example, I can publish a package under any name I want to https://hackage.haskell.org, https://crates.io, or even https://rubygems.org with very little restriction or resistance.

@quicklisp I think there should be a more clearly defined process and set of requirements for publishing to quicklisp. At least then it would be defined somewhere that you would prefer authors to not prefix packages with "quicklisp-" (although i don't agree). That's just my 2 cents. It is your project, after all, but it is very useful and could be a hub of growth.

@creichert
Copy link

This points outlined in the getting a library into quicklisp describe the the criteria pretty well. It could be more prominent.

@bhyde
Copy link

bhyde commented Aug 12, 2015

On Aug 12, 2015, at 6:31 PM, Christopher Reichert notifications@github.com wrote:

I’d be reluctant to encourage submiting a new project immediately after it was first deposited in a public repo. A bit of time to let things settle and test it seems like good practice worth encouraging.

@bhyde https://github.com/bhyde You don't have to encourage it, but there is absolutely nothing wrong with it.

Sad that our opinions diverge.

@guicho271828
Copy link
Contributor Author

just to note, I also have an idea to automatically tag quicklisp projects. It would be based on the natural language processing and keyword extraction on the documentations and README. And it would use recently added CLML. how should that library be named? should that be just one of library?

@guicho271828
Copy link
Contributor Author

also I do not think this library should be added in the next release. maybe the community needs more discussion.

@quicklisp
Copy link
Owner

@Hexstream @creichert My reluctance to add projects named "quicklisp-something" stems from the horrible confusion that ensued from asdf-install. asdf-install was a decent program with a name that made many people deeply misunderstand the relationship between it and ASDF. I wish I had chosen a different name for quicklisp-slime-helper, and for quickproject, too.

@creichert I updated this repo to make the README more prominent and link to the blog posts about adding projects. That info has also been in the FAQ for a while. I hope it helps people understand the policies I follow.

@fukamachi
Copy link

I wish I had chosen a different name for quicklisp-slime-helper, and for quickproject, too.

Well, sorry for naming "Quickdocs", btw. I suppose some people ask you about it.

@creichert
Copy link

@quicklisp Understandable, thanks for the clarification

@quicklisp
Copy link
Owner

I am going to close this for now. Please add a normal "please add" request when the time is right.

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

6 participants