After half a year of radio silence, I am trying once again to get started as committer for Lucene/Solr. I have read the documentation I could find and all the formalities seems to be in order. Next up is actually contributing anything.
I am unsure about the expected workflow here. There does not seem to be much documentation - I found https://wiki.apache.org/solr/Git%20commit%20process https://github.com/dweiss/lucene-git-guides/blob/master/04-working-dire ctly-on-a-remote-tracking-branch.sh Dawid's page suggests that I should work on the repository at https://git-wip-us.apache.org/repos/asf/lucene-solr.git There seems to be different levels here: 1) Trivial: The wiki-page suggests that for "simple JIRAs", one should simple make the changes and commit them (with rebase), with the JIRA- issue as comment. No review. Fair enough, I'll get there at some point, but for now I need some hand-holding. 2) Large: Create a SOLR-XXXXX-branch at the repo. I'll use that at some point, but it seems like overkill for the small stuff. 3) With review: Using the JIRA-system, this can be done by uploading a patch. Using the GitHub-mirror, this can be done by cloning and making a pull-request. Both methods can be used by anyone. As a committer, are these methods also preferable to get a review in the loop for smaller issues? Or is there a third and better way? If I use the GitHub-mirror, and the review process finishes successfully, how should the pull-request be closed? Will an accept be reflected at the Apache repo or should one close the pull-request without accept, and commit the code directly to the Apache-repo (by whatever method is easiest for transferring code between git repos)? Thank you, Toke Eskildsen, Royal Danish Library --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
