Oooh, nice idea!
> On Feb 3, 2020, at 10:00 AM, Cassandra Targett wrote:
>
> Our Jira is connected to Confluence and supports some pretty nice integration
> features. Instead of trying to organize 100s of issues in Jira, we could make
> a "9.0 Planning" page in Confluence and use that
Our Jira is connected to Confluence and supports some pretty nice integration
features. Instead of trying to organize 100s of issues in Jira, we could make a
"9.0 Planning" page in Confluence and use that integration to show us issue
status along our primary goals.
This integration is
+1 as well. I have seen new contributors struggle with what setting that
means... It can also set an expectation someone will just magically fix
it!
On Mon, Feb 3, 2020 at 8:21 AM Erick Erickson
wrote:
> +1 to option A.
>
> We can also remove the “fix version” whenever we notice it entered
>
*Hi Solr devs,We are trying to use Hadoop authentication with Kerberos in
Solr 8.4.1 and encountered a problem. We’re using a Hadoop 3.1.1 based
fork. We are using JDK8 so we fall back to HTTP/1.1 but also tested with
JDK11 (HTTP/2) and we got the same error.We have already added a few
upstream
I suspect your motivation for something other than a JIRA query is that
developing a JIRA query can take a few minutes whereas a simple tag to
search is less. But just a tag is less powerful and is, I think, redundant
with the existing JIRA metadata. Tags need to be maintained; if we do a
simply
Won’t add annotations. Here’s the failures in the last 4 runs:
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0 had 114 failures
Week: 1 had 125 failures
Week: 2 had 191 failures
Week: 3 had 118 failures
Failures in the last 4 reports..
Report Pct
+1 to option A.
We can also remove the “fix version” whenever we notice it entered prematurely.
There’ll still be some that sneak through, but between removing it from the
create screen and fixing it when we notice, there’ll be many fewer next time.
Which is good enough.
Yeah, using “blocker”
+1 on Option A.
[-0] on Option B. Even though it might not be everyday, I don't think
we should put roadblocks in front of users who want to clean up after
themselves. We do occasionally see users create jira issues and then
close them themselves when they realize user error or something else
bq. it seems like a huge misuse of JIRA
I disagree, but not enough to bikeshed. I’m looking for the most efficient way
to get the scope of what we want to include in 9.0 defined.
Wading through 134 issues is tedious, WDYT about a “future” tag? Once we go
through those 134 issues and change the
