You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Toke Eskildsen <to...@kb.dk> on 2017/08/15 09:21:30 UTC
Baby steps as new committer
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Dawid Weiss <da...@gmail.com>.
> Thank you, and thank you Erick. I am a bit surprised that uploading a patch is the preferred way, at least by you two. But I guess most committers have scripts in place to ease download/diff/apply?
A patch is a diff file. I just look at it directly (from Jira). In
most cases there's enough context to figure out what a change does (or
how a given think is implemented). I guess for most people there's a
level of trust that the person submitting a patch will run precommit/
tests and the feedback is about less trivial things (such as logical
issues or higher-order problems).
> I really like the GitHub pull-request-mechanism, but as I am the one asking for review of my code (in this case at least), I will of course use the method with the highest chance of getting a review.
I like it too, but I don't use it for Lucene development. And I don't
think it's that much better than a udiff (a patch file). But things
will vary depending whom you ask. This is part of why open source is
attractive to many -- it's very liberal. (Linus T. may disagree here
:).
> Related to that I am unsure about Affect/Fix versions in JIRA. The SOLR-11240 issue is present in Solr 5+, so I just picked the latest released minor version for 5 & 6 + master. Was that correct?
This is a can of worms we touched just recently... search the mailing
list and see for yourself. David Smiley (and others) suggested a
workflow, but I don't think it's been hard-locked and agreed upon by
all the devs. It seems like a sensible proposal though.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Kevin Risden <co...@gmail.com>.
> > On Tue, Aug 15, 2017 at 2:57 PM Toke Eskildsen <to...@kb.dk> wrote:
> > > Erick's explanation is perfect I think. I would only add that an issue/patch
> > > combination will typically bring more eyes to the code. If you seek
> > > feedback and want to ensure the changes are not breaking things it is
> > > the way to go.
>> Thank you, and thank you Erick. I am a bit surprised that uploading a patch is the preferred way, at least by you two. But I guess most committers have scripts in place to ease download/diff/apply?
> I don't have such scripts :-) If I see a .patch file I want to review, I usually review it by itself (don't download or apply). Of course this kinda sucks for a bunch of obvious reasons.
I typically do the following to review patches:
* Download patch from JIRA (defaults to ~/Downloads)
* git checkout branch_patch_is_based_on
* git checkout -b JIRA (ie: SOLR-10000)
* git apply -p1 ~/Downloads/$(git rev-parse --abbrev-ref HEAD).patch
** This takes the current branch name (ie: SOLR-10000) and will apply
the right patch
This is as far as I've automated it but it works pretty well for my
use cases. Sometimes I will push this to my github fork of the Apache
Lucene/Solr repo and do a compare.
Pull requests are nice if you don't have multiple people trying to
contribute at the same time. It is hard for multiple people to use PRs
to iterate on the same JIRA. Github has ways to allow contributors and
others to push to other people's PRs but not sure it is enabled for
the Apache Lucene/Solr repo. For diffing/reviewing PRs are nice and
Github makes it easy to leave review comments.
Kevin Risden
On Tue, Aug 15, 2017 at 5:07 PM, David Smiley <da...@gmail.com> wrote:
> On Tue, Aug 15, 2017 at 2:57 PM Toke Eskildsen <to...@kb.dk> wrote:
>>
>> Dawid Weiss <da...@gmail.com> wrote:
>> > Erick's explanation is perfect I think. I would only add that an
>> > issue/patch
>> > combination will typically bring more eyes to the code. If you seek
>> > feedback and want to ensure the changes are not breaking things it is
>> > the way to go.
>>
>> Thank you, and thank you Erick. I am a bit surprised that uploading a
>> patch is the preferred way, at least by you two. But I guess most committers
>> have scripts in place to ease download/diff/apply?
>
>
> I don't have such scripts :-) If I see a .patch file I want to review, I
> usually review it by itself (don't download or apply). Of course this kinda
> sucks for a bunch of obvious reasons.
>
>>
>> I really like the GitHub pull-request-mechanism, but as I am the one
>> asking for review of my code (in this case at least), I will of course use
>> the method with the highest chance of getting a review.
>
>
> I certainly favor GitHub pull requests way more than a patch, in terms of
> the reviewer experience.
>
> I suppose I tend to not do this myself for my own issues only out of habit.
> If there ultimately isn't any review, no path is particularly easier than
> the other, I think. I should try to do GitHub PRs more... though I wonder
> if it will result in more annoying dev list traffic?
>
>> Related to that I am unsure about Affect/Fix versions in JIRA. The
>> SOLR-11240 issue is present in Solr 5+, so I just picked the latest released
>> minor version for 5 & 6 + master. Was that correct?
>
>
> We just had some email thread(s) about these fields on the dev list.
>
> The "affects version" doesn't get much scrutiny... how you filled it seems
> fine. Now the "fix version/s" matters more. I believe 5.x is very EOL so
> simply don't put any 5.x version in "fix version/s" unless you really truly
> want to commit it there despite the EOL status. 6.6 was wrong because 6.6
> shipped already. I think 6.7 is appropriate since this is a minor
> improvement you're talking about here. Again, putting any 6.x version here
> implies you are going to backport it. And you missed 7.x since most new
> features will get committed to this version series, in addition to master
> which you already have listed. Essentially for every branch you are going
> to commit this to, there should be a corresponding fix-version. The actual
> branch name and JIRA "version" values aren't identically aligned but they
> are similar.
>
> ~ David
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by David Smiley <da...@gmail.com>.
On Tue, Aug 15, 2017 at 2:57 PM Toke Eskildsen <to...@kb.dk> wrote:
> Dawid Weiss <da...@gmail.com> wrote:
> > Erick's explanation is perfect I think. I would only add that an
> issue/patch
> > combination will typically bring more eyes to the code. If you seek
> > feedback and want to ensure the changes are not breaking things it is
> > the way to go.
>
> Thank you, and thank you Erick. I am a bit surprised that uploading a
> patch is the preferred way, at least by you two. But I guess most
> committers have scripts in place to ease download/diff/apply?
>
I don't have such scripts :-) If I see a .patch file I want to review, I
usually review it by itself (don't download or apply). Of course this
kinda sucks for a bunch of obvious reasons.
> I really like the GitHub pull-request-mechanism, but as I am the one
> asking for review of my code (in this case at least), I will of course use
> the method with the highest chance of getting a review.
I certainly favor GitHub pull requests way more than a patch, in terms of
the reviewer experience.
I suppose I tend to not do this myself for my own issues only out of
habit. If there ultimately isn't any review, no path is particularly
easier than the other, I think. I should try to do GitHub PRs more...
though I wonder if it will result in more annoying dev list traffic?
Related to that I am unsure about Affect/Fix versions in JIRA. The
> SOLR-11240 issue is present in Solr 5+, so I just picked the latest
> released minor version for 5 & 6 + master. Was that correct?
>
We just had some email thread(s) about these fields on the dev list.
The "affects version" doesn't get much scrutiny... how you filled it seems
fine. Now the "fix version/s" matters more. I believe 5.x is very EOL so
simply don't put any 5.x version in "fix version/s" unless you really truly
want to commit it there despite the EOL status. 6.6 was wrong because 6.6
shipped already. I think 6.7 is appropriate since this is a minor
improvement you're talking about here. Again, putting any 6.x version here
implies you are going to backport it. And you missed 7.x since most new
features will get committed to this version series, in addition to master
which you already have listed. *Essentially for every branch you are going
to commit this to, there should be a corresponding fix-version. *The
actual branch name and JIRA "version" values aren't identically aligned but
they are similar.
~ David
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Baby steps as new committer
Posted by Dawid Weiss <da...@gmail.com>.
> Ah yes. That's me being overly cautious of (non-existing) unrelated
> changes. Cherry-pick with hash is the clean way.
No worries. I typically go through what will be committed (during the
initial commit) via "git diff --cached" so that I can see whether
there's anything in the staged area that looks suspicious. This is
very much like patch reviewing, perhaps that's why I don't mind that
too.
Afterwards, if a git cherry-pick [hash] to a backward branch goes
cleanly I don't bother to check the actual changes (they are
identical), only test and push.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Toke Eskildsen <to...@kb.dk>.
On Mon, 2017-08-21 at 10:52 +0200, Dawid Weiss wrote:
> Not sure if I understand you right -- I'd just cherry-pick that
> particular commit directly from master (by its hash). Then test and
> if everything works, commit. It should merge cleanly, so no need to
> go through each file in isolation.
Ah yes. That's me being overly cautious of (non-existing) unrelated
changes. Cherry-pick with hash is the clean way.
Thank you,
Toke Eskildsen, Royal Danish Library
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Dawid Weiss <da...@gmail.com>.
> Concretely I'll patch to master and would like to back-port to 7x right
> away. As 7.0 is being rolled, 7.1 will be the entry in the change-log.
Correct.
> I will ensure that master from the Apache git repo is clean, apply the
> patch (including the update to CHANGE.txt) and commit. Then I will
> check out branch_7x and cherry-pick the changed files, check that
> everything works and commit.
Not sure if I understand you right -- I'd just cherry-pick that
particular commit directly from master (by its hash). Then test and if
everything works, commit. It should merge cleanly, so no need to go
through each file in isolation.
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Toke Eskildsen <to...@kb.dk>.
On Wed, 2017-08-16 at 08:41 -0700, Erick Erickson wrote:
> Where to put things in CHANGES is..er...complicated, I've got to go
> fix some things up myself. What I _try_ for is to only put an entry
> in the earliest version.
Concretely I'll patch to master and would like to back-port to 7x right
away. As 7.0 is being rolled, 7.1 will be the entry in the change-log.
Following https://wiki.apache.org/solr/Git%20commit%20process
I will ensure that master from the Apache git repo is clean, apply the
patch (including the update to CHANGE.txt) and commit. Then I will
check out branch_7x and cherry-pick the changed files, check that
everything works and commit.
My I-think-I-am-doing-the-right-thing confidence level is rising, but
I'll keep asking for sanity-checks for some time.
- Toke Eskildsen, Royal Danish Library
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Erick Erickson <er...@gmail.com>.
Where to put things in CHANGES is..er...complicated, I've got to go
fix some things up myself. What I _try_ for is to only put an entry in
the earliest version. We're releasing 6.6.1, and some of the stuff I
put in 6.7 will be moved to 6.6.1, so I'll move the CHANGES to 6.6.1
too. By implication, any future version is presumed to have that
change, so having an entry in 6.6.1 means it will be in 6.6.1 6.7, 7.0
and 7.1 as a policy. As always there can be exceptions, but I try to
minimize same.
On Wed, Aug 16, 2017 at 2:51 AM, Andrzej Białecki
<an...@lucidworks.com> wrote:
>
> On 16 Aug 2017, at 11:14, Toke Eskildsen <to...@kb.dk> wrote:
>
> On Tue, 2017-08-15 at 13:10 -0700, Erick Erickson wrote:
>
> [Git pull vs. patch]
>
> It seems like a patch is the simplest path for a simple fix, so I'll
> start there.
>
> It's confusing to fill in the "Fix version" until you "Resolve" the
> issue, i.e. commit a fix. I leave it blank when raising a JIRA, only
> filling it in when I commit the fixes.
>
>
> That makes sense. I'll adjust when I upload a patch. I'll forget about
> version 5 & 6 and just go for master. When 7.0 has been released, I
> would like to port to 7.1 (we need the fix ourselves for 7.x, so I
> might as well port it for everyone). Or can I port to 7.1 already? I am
> not sure about the state of branches when a release is in progress.
>
>
> There’s a branch_7x for future 7.x releases, including 7.1 - you can go
> ahead and port & commit to that branch. Commits to branch_7_0, which is the
> release branch, should be approved by release manager (for 7.0 this is
> Anshum).
>
> There’s a complicated issue of where to put the CHANGES.txt entry … my take
> on this is that if you know in advance what is the oldest version where the
> fix will be applied, you should add the entry to that section, no matter if
> you first commit to master or some other branch - eg. add it to the section
> on 7.0 if that’s where it first appeared.
>
>
> I read the "Strange Solr JIRA versions"-thread and what I got from it
> is that I should never type in the version field in JIRA (only use the
> drop-down) and that I to stay clear of any 'x'-versions, should they be
> created by others.
>
>
>
> Thank you,
> Toke Eskildsen, Royal Danish Library
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Andrzej Białecki <an...@lucidworks.com>.
> On 16 Aug 2017, at 11:14, Toke Eskildsen <to...@kb.dk> wrote:
>
> On Tue, 2017-08-15 at 13:10 -0700, Erick Erickson wrote:
>
> [Git pull vs. patch]
>
> It seems like a patch is the simplest path for a simple fix, so I'll
> start there.
>
>> It's confusing to fill in the "Fix version" until you "Resolve" the
>> issue, i.e. commit a fix. I leave it blank when raising a JIRA, only
>> filling it in when I commit the fixes.
>
> That makes sense. I'll adjust when I upload a patch. I'll forget about
> version 5 & 6 and just go for master. When 7.0 has been released, I
> would like to port to 7.1 (we need the fix ourselves for 7.x, so I
> might as well port it for everyone). Or can I port to 7.1 already? I am
> not sure about the state of branches when a release is in progress.
There’s a branch_7x for future 7.x releases, including 7.1 - you can go ahead and port & commit to that branch. Commits to branch_7_0, which is the release branch, should be approved by release manager (for 7.0 this is Anshum).
There’s a complicated issue of where to put the CHANGES.txt entry … my take on this is that if you know in advance what is the oldest version where the fix will be applied, you should add the entry to that section, no matter if you first commit to master or some other branch - eg. add it to the section on 7.0 if that’s where it first appeared.
>
> I read the "Strange Solr JIRA versions"-thread and what I got from it
> is that I should never type in the version field in JIRA (only use the
> drop-down) and that I to stay clear of any 'x'-versions, should they be
> created by others.
>
>
>
> Thank you,
> Toke Eskildsen, Royal Danish Library
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Baby steps as new committer
Posted by Toke Eskildsen <to...@kb.dk>.
On Tue, 2017-08-15 at 13:10 -0700, Erick Erickson wrote:
[Git pull vs. patch]
It seems like a patch is the simplest path for a simple fix, so I'll
start there.
> It's confusing to fill in the "Fix version" until you "Resolve" the
> issue, i.e. commit a fix. I leave it blank when raising a JIRA, only
> filling it in when I commit the fixes.
That makes sense. I'll adjust when I upload a patch. I'll forget about
version 5 & 6 and just go for master. When 7.0 has been released, I
would like to port to 7.1 (we need the fix ourselves for 7.x, so I
might as well port it for everyone). Or can I port to 7.1 already? I am
not sure about the state of branches when a release is in progress.
I read the "Strange Solr JIRA versions"-thread and what I got from it
is that I should never type in the version field in JIRA (only use the
drop-down) and that I to stay clear of any 'x'-versions, should they be
created by others.
Thank you,
Toke Eskildsen, Royal Danish Library
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Erick Erickson <er...@gmail.com>.
Toke:
bq: there's a git wizard sitting 5 meters from me
Lucky you
bq: I am a bit surprised that uploading a patch is the preferred way...
I wouldn't necessarily call it "preferred", just how I "grew up" with
working on Solr. It's really up to you. I'm just being pulled kicking
and screaming into the Git world from SVN (and we won't talk about CVS
from a looong time ago). Someday I'll get with the modern world and
get comfortable with pull requests. From my perspective as long as we
have a permanent way to reconstruct the changes it's then personal
preference.
The only advantage of the patch process is it's self-contained on the
JIRA. IntelliJ has an "Git>>Apply patch" menu choice to make applying
patches easy. I've messed up a few times creating patches b/c I
understood even less about Git than I do now though...
"Affects version" is mostly used as a marker for the version someone
noticed it on when they raised the JIRA, just because the "affects
version" is 6.5 says nothing about whether it is 6.4 or 5.3 etc. and
_probably_ means it's still a problem in 7.0.
It's confusing to fill in the "Fix version" until you "Resolve" the
issue, i.e. commit a fix. I leave it blank when raising a JIRA, only
filling it in when I commit the fixes.
The consensus last I knew was to "Resolve" an issue when you commit a
fix and leave it to the Release Manager to "Close" the issue when a
release is made.
Most generally the process for fixing something is:
> work on master (currently 8.0)
> commit to master
> merge into 7x
> commit to 7x
Note there is no mention of even the 7_0 branch, that's only getting
critical bug fixes as Anshum is working through the release process.
Once a release is made, we try mightily to _not_ backport anything
else to it except critical bug fixes. If you really want to, you can
commit some "nice to have" bug fixes to a branch once it's released
just in case there's another point release (e.g. backport something to
branch_7_0 just in case there's 7.0.1) but that's totally optional.
There's no need to bother with prior versions (even 7_0 at this point)
unless there's a compelling need/critical bug fix or you have a need.
We're currently in process (well, Varun Thacker is in the process) of
releasing a 6.6.1, but that's only to fix some bugs and put a bow on
the 6.x code line. Nobody is committing there if they can avoid it
currently.
At this point it'll be increasingly rare for anyone to put anything
more in the 6x code line. You may notice that there are a series of
changes to 6x that _would_ have been in a 6.7 release, but those were
put in "just in case" there was a 6.7 before 7.0 came out. It looks
like we've settled on _not_ being a 6.7 however, so I view these
changes as something someone can compile on their own if they want to
but not something we'll release. Therefore not something I'll commit
anything to regularly.
The 5x code line would only get any fix that you intended to release a
point version yourself. The community wouldn't get involved for
anything less critical than, say, a security vulnerability.
Best,
Erick
On Tue, Aug 15, 2017 at 11:57 AM, Toke Eskildsen <to...@kb.dk> wrote:
> Dawid Weiss <da...@gmail.com> wrote:
>> Erick's explanation is perfect I think. I would only add that an issue/patch
>> combination will typically bring more eyes to the code. If you seek
>> feedback and want to ensure the changes are not breaking things it is
>> the way to go.
>
> Thank you, and thank you Erick. I am a bit surprised that uploading a patch is the preferred way, at least by you two. But I guess most committers have scripts in place to ease download/diff/apply?
>
> I really like the GitHub pull-request-mechanism, but as I am the one asking for review of my code (in this case at least), I will of course use the method with the highest chance of getting a review.
>
>> If you are not sure about git, feel free to ask.
>
> Thank you. I am reasonably used to git and there's a git wizard sitting 5 meters from me, so the things I am unsure of is mostly how it is applied specifically for Lucene/Solr.
>
>
> I'll try creating a patch from git tomorrow for SOLR-11240 and take it from there.
>
> Related to that I am unsure about Affect/Fix versions in JIRA. The SOLR-11240 issue is present in Solr 5+, so I just picked the latest released minor version for 5 & 6 + master. Was that correct?
>
> Thank you,
> Toke Eskildsen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Toke Eskildsen <to...@kb.dk>.
Dawid Weiss <da...@gmail.com> wrote:
> Erick's explanation is perfect I think. I would only add that an issue/patch
> combination will typically bring more eyes to the code. If you seek
> feedback and want to ensure the changes are not breaking things it is
> the way to go.
Thank you, and thank you Erick. I am a bit surprised that uploading a patch is the preferred way, at least by you two. But I guess most committers have scripts in place to ease download/diff/apply?
I really like the GitHub pull-request-mechanism, but as I am the one asking for review of my code (in this case at least), I will of course use the method with the highest chance of getting a review.
> If you are not sure about git, feel free to ask.
Thank you. I am reasonably used to git and there's a git wizard sitting 5 meters from me, so the things I am unsure of is mostly how it is applied specifically for Lucene/Solr.
I'll try creating a patch from git tomorrow for SOLR-11240 and take it from there.
Related to that I am unsure about Affect/Fix versions in JIRA. The SOLR-11240 issue is present in Solr 5+, so I just picked the latest released minor version for 5 & 6 + master. Was that correct?
Thank you,
Toke Eskildsen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Dawid Weiss <da...@gmail.com>.
Erick's explanation is perfect I think. I would only add that an
issue/patch combination will typically bring more eyes to the code. If you
seek feedback and want to ensure the changes are not breaking things it is
the way to go.
If you are not sure about git, feel free to ask. Although experimenting on
a local repo and gitk --all shows a lot more than human explanations I
think :)
Dawid
On Aug 15, 2017 16:30, "Erick Erickson" <er...@gmail.com> wrote:
Toke:
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...
Best,
Erick
On Tue, Aug 15, 2017 at 7:12 AM, Shashank Tyagi
<sh...@gmail.com> wrote:
> +1
>
> On Tue, Aug 15, 2017 at 2:51 PM, Toke Eskildsen <to...@kb.dk> 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
>>
>> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Erick Erickson <er...@gmail.com>.
Toke:
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...
Best,
Erick
On Tue, Aug 15, 2017 at 7:12 AM, Shashank Tyagi
<sh...@gmail.com> wrote:
> +1
>
> On Tue, Aug 15, 2017 at 2:51 PM, Toke Eskildsen <to...@kb.dk> 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
>>
>> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Baby steps as new committer
Posted by Shashank Tyagi <sh...@gmail.com>.
+1
On Tue, Aug 15, 2017 at 2:51 PM, Toke Eskildsen <to...@kb.dk> 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
>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>