Hi Steve,
thanks for the support.
I spent some time yesterday experimenting and testing, and adding a new
patch to the mentioned Jira issues ( which are already in a "Patch
Available" status) and I definitely saw the jobs being queued by Jenkins (
Hi Alessandro,
Thanks for bringing these issues to light, I didn’t know about them.
I’ve seen patches take up to 18 hours prior to triggering a validation job, but
I’ve never seen one take longer than that.
For both these JIRAs, I suspect that Yetus’s partial/experimental support for
linked
There will be a few false positives for these two JIRA queries (commits
that didn't fully fix the issue) but the three I listed above are there:
Check for Git commit:
project in (SOLR, LUCENE) AND status in (Open) and fixVersion is not empty
and text ~ "in lucene-solr's branch refs/heads/" order
Here are three that I just happened upon and was semi familiar with:
* SOLR-8097
* SOLR-9058
* SOLR-8878
Looks like they just need to be resolved properly and fix the fixVersion.
there might be just as many open issues w/o a fixVersion that warrant equal
> review/edits.
Yea that is probably
: I wasn't suggesting a blanket resolve of issues. There are a few that I
: looked at that should have been resolved and weren't. This would require
: some manual effort.
can you give some examples?
I was reading "resolved" as "FIXED" but if you're talking about issues
that could/should be
> TLDR: I don't think it's worth any time/effort to worry about fixVersion
> for open issues.
>
Thats fair and your explanation makes a lot of sense.
I'm not sure why you think it would be a good idea to blanket resolve
> issues with older fix versions -- that seems to be confusing cause with
>
TLDR: I don't think it's worth any time/effort to worry about fixVersion
for open issues.
: project in (SOLR,LUCENE) and status in (Open) and fixVersion IS NOT EMPTY
:
: Does it make sense that there are so many issues that are open and have a
: fixVersion that is not empty?
Yes, there are
On Wed, May 18, 2011 at 10:53 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: just a few words. I disagree here with you hoss IMO the suggestion to
: merge JIRA would help to move us closer together and help close the
: gap between Solr and Lucene. I think we need to start identifying us
On Tue, May 17, 2011 at 9:23 PM, Steven A Rowe sar...@syr.edu wrote:
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them
I didn't know that it was decided that top-level modules issues go under the
Lucene project. That indeed reduces some of the confusion (as long as users
will adhere to it, but I guess it's also up to us to enforce it).
So Lucene project becomes everything that is not precisely Solr, i.e. not
On Tue, May 17, 2011 at 10:23 PM, Steven A Rowe sar...@syr.edu wrote:
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them
: I didn't know that it was decided that top-level modules issues go under the
: Lucene project. That indeed reduces some of the confusion (as long as users
: will adhere to it, but I guess it's also up to us to enforce it).
And as noted: moving a Jira issue from SOLR-LUCENE (or vice versa) is
: just a few words. I disagree here with you hoss IMO the suggestion to
: merge JIRA would help to move us closer together and help close the
: gap between Solr and Lucene. I think we need to start identifying us
: with what we work on. It feels like we don't do that today and we
: should work
+1 to Chris.
Even if the code is partially shared and project is the same, the end
products are completely different.
Merging lists/jira will force niche developers/users to manually sift
through heaps of irrelevant emails/issues.
On Thu, May 19, 2011 at 00:53, Chris Hostetter
On May 17, 2011, at 2:22 PM, Shai Erera wrote:
Can we merge the two?
+1. Due to history and other possible pain points, I don't know that it's the
right practical idea at the end of the upcoming discussion, but it's certainly
a good idea.
- Mark Miller
lucidimagination.com
Lucene/Solr User
Can we merge the two?
gut reaction says +1, but after thinking about how it would work, i'm +0
Would we just stop accepting new tickets on one system, but still keep
track of both? for how long?
Would we move open issues from SOLR to LUCENE? migrate the comments/history/etc
In the end I
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them distinct -- partly from a pain of migration
standpoint on our end, but also from a user expecations standpoint -- i
think
On 5/17/2011 at 3:02 PM, Chris Hostetter wrote:
If we were starting from scratch, i'd agree with you that having a single
Jira project makes more sense, but given where we are today, i think we
should probably keep them distinct -- partly from a pain of migration
standpoint on our end, but
18 matches
Mail list logo
