-
Notifications
You must be signed in to change notification settings - Fork 674
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
SOLR-15242: Consolidate README.md with solr/README.md #610
Conversation
…acing the existing README.md and solr/README.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for doing this Eric. Some random comments
README_v2.md
Outdated
For documentation on using the official docker builds, please refer to the [DockerHub page](https://hub.docker.com/_/solr). | ||
Up to date documentation for running locally built images of this branch can be found in the [local reference guide](solr/solr-ref-guide/src/running-solr-in-docker.adoc). | ||
|
||
There is also a gradle task for building custom Solr images from your local checkout. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps add a link to dev-docs/docker.adoc
- eeh, no, wait that does not exist, I meant help/docker.txt
-- eh, sorry, wrong again, it should be solr/docker/gradle-help.txt
(why on earth do we have dev-docs spread out this much?) so we don't need to say so much about building Docker locally in the main README.
Hmm, looking a few lines down, I now see that ./gradlew helpDocker
actually points to that txt file, but that is not consistent either, would expect all help files to exist in help/.. Well, well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to take this as "it's okay" for now then on this comment? Quite agree on your frustration!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for that placement, there was discussion at the time, but it is long forgotten. I'd be happy to move it to wherever it will make the most sense 🙂
README_v2.md
Outdated
system. Navigate to the root of your source tree folder and issue the `./gradlew tasks` | ||
command to see the available options for building, testing, and packaging Solr. | ||
|
||
`./gradlew assemble` will create a Solr executable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps highlight the ./gradlew dev
task instead, as it it creates a build on a stable path and is made for quick developer cycles. Then we won't need to change the README for every release either, replacing the solr-9.0.0-SNAPSHOT
string :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion. I added a mention of assemble
later on.
README_v2.md
Outdated
you may find useful in working with Solr. | ||
|
||
|
||
### Gradle build and IDE support |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General about building from source and gradle - perhaps we should make some really good and thorough guides about that topic in dev-docs
, and just have a few really basic examples here in the main readme, like ./gradlew dev
and cd solr/packaging/dev/ && bin/solr -e techproducts
...
But i see that the main focus here is merging the two READMEs, so feel free to postpone dev-docs work to later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the sentiment! We should rationalize more the dev-docs
and the stuff in ref guide related to development. Or just put dev-docs
etc in Ref Guide!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That can be done in followup issues. I think we plan for a separate dev-guide, and not mash everything into ref-guide.
README_v2.md
Outdated
|
||
## Contributing | ||
|
||
Please review the [Contributing to Solr Guide](https://cwiki.apache.org/confluence/display/solr/HowToContribute) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later, the result of https://issues.apache.org/jira/browse/SOLR-15682 will be linked here...
Just added some getting started based on what @chatman did in apache/lucene-solr#2594, thoughts @janhoy ??? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The README looks great, thanks for taking this on Eric.
I have a few questions conceptually about what should be in a top-level README. Most projects I looked up (Kube, Elasticsearch, Opensearch, ZooKeeper, Vespa) have READMEs that are focused pretty tightly on "meta" information: what the project is, contribution, licensing. In these examples, more concrete information (tutorials, docker setup, and detailed startup or development instructions) are covered by sometimes a short blurb and a link out to some other location.
I like that setup personally: it avoids duplication in things like tutorials, and (IMO) runs less risk of overwhelming new users with a wall of text and unfamiliar concepts right out of the gate.
But assuming we're consciously choosing this more inclusive approach, I think this PR is a great stab at it. The prose is clear and the tutorial is helpful
README_v2.md
Outdated
# Welcome to the Apache Solr project! | ||
----------------------------------- | ||
|
||
Solr is the popular, blazing fast open source enterprise search platform |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
blazing fast open source enterprise search platform
[0] It feels weird to single out enterprise search here as being our main (only?) use case. We're also an ecommerce search engine, and an analytics engine, etc.
(I understand this language is probably carried over from one of the existing READMEs, and used in many places...no need to fix it here necessarily if you're not interested.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I completely agree with you @gerlowskija on this... It IS front and center on the website at https://solr.apache.org/ ;-(. Worth a seperate ticket?
Solr is the popular, blazing fast open source search platform for your enterprise, ecommerce, and analytics needs
???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, we should fix it everywhere. I changed the Official docker image description to remove it. But we should standardize around a common language, and set that everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@HoustonPutman you want to open a ticket? If you get the consensus, I'd volunteer to do the updates ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://issues.apache.org/jira/browse/SOLR-16295
We can brainstorm there
README_v2.md
Outdated
visit the [Solr Reference Guide](https://solr.apache.org/guide/). | ||
|
||
## Getting Started | ||
FIXME maybe put the tutorial that Noble or Ishan wrote??? Then at the end put the examples? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Q] Alternatively - do we really want a full blown tutorial in our README? At best, it duplicates documentation we have elsewhere. At worst it makes it harder to find the information the reader actually came for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that we shouldn't have a full-blown tutorial here. We should have links to our actual tutorials, and enhance them if need be.
If we do keep a tutorial here, let's put other stuff before it, like the docker and kubernetes sections. These are smaller and are really just advertising other documentation/sites that people should be checking out.
README_v2.md
Outdated
|
||
``` | ||
curl --request POST \ | ||
--url http://localhost:8983/api/collections \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[+1] Thanks for the effort to use the v2 APIs!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[-0] If we are trying to fixup the v2 APIs before marketing them, lets unfortunately continue to use the v1 APIs until they are ready.
(If we plan on keeping the tutorial section)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are trying to fixup the v2 APIs
I guess that makes sense, unfortunately. I'd love to get these APIs mostly locked in as soon as we can though, so that we can start pushing them. On that note: anyone reading this should go review the proposed changes to the v2 API here 😛
README_v2.md
Outdated
|
||
## Export control | ||
|
||
This distribution includes cryptographic software. The country in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Q] Is there a legal requirement to have this here, or is it here for practical purposes?
(i.e. This mostly looks like legal boilerplate to me, but I'm not an expert so maybe there's actual nuggets in here useful to sysadmin/security folks?)
Assuming this is here for legal reasons: looking at other projects (e.g. Elasticsearch, Vespa, Zookeeper) who use cryptography similar to Solr, none of them mention export controls in their top level repositories. Maybe we're the rare case of a project actually doing what's legally required, but I suspect we actually don't need this here.
(Also, ./gradlew dependencies
makes me think we no longer pull in bouncycastle from TIKA as this suggests.)
Hey all.... I am getting the feeling that README_V2 is trying to do too many things. Is it hear to extoll the virtues of Solr? Be your onboarding tutorial? Provide all the depth of the main solr.apache.org site? I'm going to craft a README_V3 to compare with README_V2 that is narrower in focus and follows more in the vein of other projects with more links. |
So... check out README_V3.md, which I just put "chapter headings" and some comments.... |
Okay, I think I am liking V3 a lot more over V2... Thoughts? Should I move the tutorial into the ref guide? I like how it uses the new apis and is super compact.... "Index and Query in Five Minutes with Solr" |
I like the new v3 implementation a lot! We do need to keep a separate Readme for the binary distribution, but we can keep that in Also maybe the v3 readme should have a section that explains each super (or sub |
@HoustonPutman I'll take it that I'm on the right track.... I'll try and add a solr/packaging/README.md the way you suggested. I do think trying to explain the code etc is better int he dev docs, and not have the README do too much. Also, I tried to make it easier to call out resources for new dev's to join. I keep meeting folks who contribute patches and yet ARE NOT on the dev mailing list, or the slack channel for development work... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good to go @epugh !
Consolidate the ./README.md and ./solr/README.md into a new top level README.md optimized for Github. The /solr/README.adoc is now to help a developer understand what the subdirectories are all about. Introduced a new README.txt in the ./solr/packaging directory to ship with the distributions. Co-authored-by: [email protected] <> Co-authored-by: Jan Høydahl <[email protected]> Co-authored-by: Houston Putman <[email protected]>
https://issues.apache.org/jira/browse/SOLR-15242
Description
Consolidate README.md with solr/README.md
Solution
Trying not to duplicate things, trying to not get in TOO much depth, but give enoguh so that folks who go to github.com/apache/solr have a nice experience!
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:
main
branch../gradlew check
.