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 <[email protected]> wrote: > Dawid Weiss <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
