I wrote quickly and didn't expound much, let me clarify that my comments
are in reference to having bug tracking in GitHub. Using the mirror doesn't
bother me since the system of record is apache gitbox (the GitHub mirror is
WAY better UI than gitbox). Having the record of what bugs were resolved i
I think it makes sense to just bundle the code and ref guide release into
one. Right now, it's been Cassandra and Hoss who have taken care of the ref
guide, but that shouldn't be the case.
It might mean that the ref guide is a little behind when the code releases,
but then we should just be better
Also, just FYI, I say that as someone that kind of prefers patches and JIRA
for 90% of what I do. I’ve been doing this same shit for like half my life,
I’m not looking for fancy new tools for the hell of it either. I like
patches. It’s just going to happen. And I see a huge pool of free resources
i
I think that is a little over the top.
As it is the majority of dev and pr's and action is moving to GitHub,
whether anyone is from Syria or not.
If we decided, like most other communities on Gods green earth, to tell our
community we are going GitHub first it and expect committers to not avoid
a
Hi Adrien,
Indeed, meant to write about starting a vote.
@Gus, I'll have to let Cassandra weigh in on this one as I'm not very
familiar with the ref guide release process.
Regards,
Ishan
On Mon, 16 Sep, 2019, 7:28 PM Adrien Grand, wrote:
> +1 to start working on 8.3
>
> Did you mean "start a v
Ok, I buy that reason for leaving the ASF controlled mechanism.
On Tue, Sep 17, 2019 at 2:16 PM Chris Hostetter
wrote:
>
> : Is there any reason at all that we need to hold on to JIRA? ASF allows
> : us to move all issue handling over to GH, I'd like us to consider such a
> : move.
>
> In my opi
"means pressuring people into accepting the github TOS"
That's a really good point. Hadn't thought of that and it's definitely not
ok to put github in control (or make them able to force a sudden burden of
work when we don't like what they did). Apache should determine it's own
destiny, and for th
: Is there any reason at all that we need to hold on to JIRA? ASF allows
: us to move all issue handling over to GH, I'd like us to consider such a
: move.
In my opinion, migrating from JIRA to Github "issues" would be a terrible
idea.
I have no objections to the goal of "encouraging" and "f
I think standardizing the approach to contributing would be a great thing.
It might mean not accommodating everyone's preference, but then it would
mean that the people who want to review are all on the same page. Else
people who prefer git will rarely look at patches, and the other way around.
Th
I think I may prefer JIRA to GitHub Issues. I'm not sure.
Anyway, it's worth wondering if we can just move JIRA to GitHub. GitHub is
now a first class mirror for Apache that we can commit to, but they still
keep a primary copy of our code at Apache. Perhaps that is only a code
concern now though.
Hi Uwe & Dawid,
*Release Announcement: General Availability of Java 13 / JDK 13 [1] *
* JDK 13, the reference implementation of Java 13, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/13
* Release notes - https://jdk.java.
I mentioned when we chatted at activate that I had a build in the past that
was doing some pulling of gems... Looked back and it was actually using
https://github.com/robfletcher/gradle-compass which was doing the gem
management. Seems to use https://github.com/jruby-gradle/jruby-gradle-plugin to
p
Well put Jason. I think we didn't discuss it in any further detail than
what you said right here -- basically cater to GitHub PRs and either
discourage or undocument "patch file" based contributions. That's it in a
sentence. We all nodded our head to that, albeit some of us like me
confess to en
RE the idea of shash-merge from a PR: that would be cool were it not for
CHANGES.txt; ah well.
+1 to "put it in the PR template checklist"
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Tue, Sep 17, 2019 at 2:37 PM Jan Høydahl wrote:
> I like th
bq. Are we free to commit to that gradle branch or do you prefer PRs?
Commit away unless you are looking for feedback and a PR makes it easier.
I held onto it for long enough :) Time to get some more blood in this thing.
Also, if there are any things or parts that are important and you don't
hav
I like the idea to put it in the PR template checklist. Or you can ask the
contributor to check that box. I once made a PR against another PR branch and
it worked but was too many steps.
I like the idea of squash-merging from PR branch since (I believe) the commit
will then have the credit of t
I got started on the Ref Guide build last night. The biggest change there is to
use the asciidoctor-gradle-plugin instead of using the asciidoctor-ant plugin.
So far I’ve got it working enough to build a single page of the Ref Guide into
a PDF file. Baby steps ;)
By itself that only gets us the
We discussed this already on Berlinbuzzwords (Mike and Michael). Yes it's
possible and may work for merges where block io is possible. But most of us
said: it's fine to not use io cache for merging, but it won't make pages hot.
So merges are invisible to OS, so you have to warm merged segments i
Isn't that restricted to aligned block-only access though? I can
imagine this would complicate the implementation if somebody wanted to
use it directly.
Dawid
On Tue, Sep 17, 2019 at 5:37 PM Michael McCandless
wrote:
>
> Whoa! That would be awesome -- no more JNI to use Direct I/O?
> Looks like
Yep, I'll work on that this afternoon.
On Tue, Sep 17, 2019 at 12:24 PM Anshum Gupta
wrote:
> Sounds like a good idea, Houston.
> Do you plan on creating a JIRA and PR ?
>
> On Tue, Sep 17, 2019 at 9:17 AM Houston Putman
> wrote:
>
>> The startup options for the Prometheus Exporter are pretty s
Sounds like a good idea, Houston.
Do you plan on creating a JIRA and PR ?
On Tue, Sep 17, 2019 at 9:17 AM Houston Putman
wrote:
> The startup options for the Prometheus Exporter are pretty sparse compared
> to what the Solr start script offers.
>
> I'm looking at adding some options that mirror
The startup options for the Prometheus Exporter are pretty sparse compared
to what the Solr start script offers.
I'm looking at adding some options that mirror what Solr offers, such as
- SOLR_HEAP
- SOLR_JAVA_MEM
Maybe some GC options as well.
Having just the memory settings available w
Whoa! That would be awesome -- no more JNI to use Direct I/O?
Looks like you use it like this:
FileChannel fc = FileChannel.open(p, StandardOpenOption.WRITE,
ExtendedOpenOption.DIRECT
But it looks like you need to enable the jdk.unsupported module, added with
ht
Github does have an option that fork-owners can click when they create
a PR that will give those with karma on the upstream repo the same
karma on their PR branch. [1] That would solve this problem somewhat.
But it's still up to users to choose that themselves. Maybe it makes
sense to mention thi
Hey all,
I've hit a small snag reviewing a few PRs on github recently. Wanted
to see if anyone has any suggestions for my workflow:
I’ve found myself in the position a few times where I want to add a
few small changes to a contributor’s PR…either to help them with a
piece they haven’t gotten to
I missed the part of the meeting/lunch when our use of Github came up.
Can anyone that was present summarize the discussion in a little more
detail?
re: issues on github. There are challenges like avoiding
fragmentation and keeping multiple issue sources up to date, but those
are problems that pr
Ah.. The mythical committer just sitting around waiting to be “interested in
the issue” that you have created! Having said that, I think thats a separate
challenge!
> On Sep 17, 2019, at 12:38 AM, David Smiley wrote:
>
> +1 to all that Gus said. On a fresh project then indeed perhaps we
> [...] last I remember Dawid signed up for it starting around today (15th) ;)
Ah... so you remembered?... Kind of hoped you forgot. :)
I'll take a look and try to tackle some of Chris's questions. Are we
free to commit to that gradle branch or do you prefer PRs?
D.
28 matches
Mail list logo
