lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: Baby steps as new committer
Date Tue, 15 Aug 2017 14:29:56 GMT

There's also 1.5, between commit with no review/notice (docs spring to
mind) and creating a branch (this is usually when you want to work
with others) and that's "bigger patches without branching". My rule of
thumb is that if I'm likely to be the person doing most/all of the
work I'll just make a patch without a branch, post it for review and
then commit. We have had 200K+ patches ;).

And there's no formal review process, nobody has to "sign off" on a
patch. If you're a committer you can commit it when you think it's
ready. That said I've been saved more times than I want to admit by
someone looking at a patch and, er, pointing things out that could
have been done better.

My personal process is to put up a patch (I prefer them to Git pulls,
but that's a personal preference) and say "I think this is ready to
commit, any comments?" If I don't get any feedback on a proposed patch
I'll usually say something like "I'm committing this in 2 days if
nobody objects" then do it.

About Git I'll leave to people who know it better...


On Tue, Aug 15, 2017 at 7:12 AM, Shashank Tyagi
<> wrote:
> +1
> On Tue, Aug 15, 2017 at 2:51 PM, Toke Eskildsen <> wrote:
>> 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
>> Dawid's page suggests that I should work on the repository at
>> 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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message