I deleted all "merged" branches.
I'd agree that it's a good custom to push feature branches into forked
local repos, not the master repo (unless it's really necessary).
For the moment, please check branches you created and delete obsolete ones.
https://github.com/apache/lucene-solr/branches/all
On Mon, Oct 19, 2020 at 5:17 PM David Smiley wrote:
> I ask you all to do the following:
>
> git config --global pull.rebase true
>
>
+1
It's what you want 99% of the time.
-Yonik
I ask you all to do the following:
git config --global pull.rebase true
Perhaps you have already set it as such (this retrieves the current
setting, possibly a default):
git config pull.rebase
-> true
*What*: As the setting implies, this has to do with what happens on a
"pull", but in
On Mon, 19 Oct 2020 at 14:24, Uwe Schindler wrote:
> Nice possibility on top: You can force push as often as you like! ☕藍
>
Up until the point you create a PR. After that, I think it gets confused
and doubles the entries. Unless I messed up one of my PRs even worse than I
thought.
+1 on doing
Nice possibility on top: You can force push as often as you like! ☕藍
Am October 19, 2020 6:18:59 PM UTC schrieb Erick Erickson
:
>+1, this is what I’ve been doing for a while, and it gives me a warm
>fuzzy feeling to know that no mater what, until the final merge into
>the master repo I can’t
+1, this is what I’ve been doing for a while, and it gives me a warm fuzzy
feeling to know that no mater what, until the final merge into the master repo
I can’t inadvertently screw up said master repo….
> On Oct 19, 2020, at 1:53 PM, David Smiley wrote:
>
> +100 to Uwe's total message -- my
+100 to Uwe's total message -- my thoughts exactly. When I first started
using GitHub, I had an SVN mindset and didn't recognize the point of repo
forks. Now I can clearly see that it allows for PRs that don't pollute the
branches in the master repo.
On Mon, Oct 19, 2020 at 1:01 PM Uwe
FYI I pushed a fix for a test-only bug introduced by LUCENE-9524.
On Mon, Oct 19, 2020 at 2:47 PM Jan Høydahl wrote:
> I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change which fixes
> a bug in grafana dashboard JSON.
>
> Jan
>
> > 19. okt. 2020 kl. 11:54 skrev Atri Sharma :
> >
> >
Thanks, this is now merged. There’s another one that I just filed: SOLR-14948.
This is a bug in the autoscaling code that prevents using the maxOps override
in ComputePlanAction. It’s a straightforward change (wrong numeric type was
cast) so I’d like to merge this too.
> On 19 Oct 2020, at
Hi Tomoko,
IMHO, people should open PRs using a branch on their own GitHub fork. It also
works well when you work together. Any ASF org member on GitHub can
automatically commit and push to private branches of outside users, as GitHub
enforces you to allow pushes from members of the org the PR
Thank you Jan for the pointer.
I read the Infra wiki, and checked the yaml files in several major ASF
repositories (e.g. Hadoop, Flink, Kafka, AIrflow, ...). It looks like there
is no such configuration for the feature.
If it's ok I will delete all branches that have been already merged.
Also I'd
I think this is a really good idea. Formalizing the process would certainly
help with consistency throughout Solr. Thanks for bringing it up Noble!
Andrzej, we could possibly use a label for this in JIRA, or add a
"component" for it. Adding it as a part of the checklist is a good idea,
especially
Check the .asf.yml file in our repo and
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
That’s where we control github features… But I cannot see that option.
Jan
> 19. okt. 2020 kl. 16:20 skrev Tomoko Uchida :
>
> Hi,
> it seems there are many active branches that
Hi,
it seems there are many active branches that are already merged into master
via Github PR.
Github has a configuration to automatically delete the branch when a PR is
merged (Settings -> Options -> "Automatically delete head branches") but I
think it is disabled by default.
I cannot change the
Hmm looks like a randomized failure in a new test case I just added.
I'll take a look
On Sun, Oct 18, 2020 at 8:16 PM Policeman Jenkins Server
wrote:
>
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/28367/
> Java: 64bit/jdk-14.0.1 -XX:-UseCompressedOops -XX:+UseG1GC
>
> 1
I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change which fixes a
bug in grafana dashboard JSON.
Jan
> 19. okt. 2020 kl. 11:54 skrev Atri Sharma :
>
> Fixed the issue. Cherry picking to branch_8_7 now.
>
> Apologies, I must have created branch_8_x accidentally. Let me delete.
>
>
The BadApple report remains skewed as the results include the reference impl so
this is mostly in case people are curious….
I expect next week to see an uptick in the number of tests that have failed
each of the last 4 weeks, that’ll be when the reference-impl parts of the
report kick in.
ab,
Please proceed to commit to 8x and 8_.
On Mon, Oct 19, 2020 at 3:24 PM Andrzej Białecki wrote:
>
> Atri,
>
> I’d like to add a notice in 8.7.0 (no code change) to CHANGES.txt about the
> deprecation of the spinning disk detection (LUCENE-9576 and SOLR-14930).
>
>
> On 19 Oct 2020, at
Fixed the issue. Cherry picking to branch_8_7 now.
Apologies, I must have created branch_8_x accidentally. Let me delete.
On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand wrote:
>
> 1. This is failing 8.7 builds, e.g.
> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, so
Atri,
I’d like to add a notice in 8.7.0 (no code change) to CHANGES.txt about the
deprecation of the spinning disk detection (LUCENE-9576 and SOLR-14930).
> On 19 Oct 2020, at 05:55, David Smiley wrote:
>
> Given how recent branch_8_7 was cut, I don't think a RC should be released
> Monday.
20 matches
Mail list logo
