Anyone have opinions on dealing with "combined issues" in JIRA.  By this, I mean, issues that involve both changes to Lucene and Solr.  For instance, I'm doing some work on the spell checker right now, which I am then immediately implementing in the SpellCheckComponent.  It seems silly to first open a Lucene issue in JIRA and then also open a Solr issue and link it back to the Lucene issue, especially when it is a smaller fix.

I think I would prefer to just be able to refer to Lucene issues from time to time in Solr's CHANGES.txt file and obviously, the patch would contain the fix across the source.  Thoughts?

-Grant
---------------------------------------------------------------------

On Wed, Aug 18, 2010 at 10:48 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> Anyone have opinions on dealing with "combined issues" in JIRA.  By this, I mean, issues that involve both changes to Lucene and Solr.

It often makes sense - we've had a lot of patches that go across both already.

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------

>> I think I would prefer to just be able to refer to Lucene issues from time to time in Solr's CHANGES.txt file and obviously, the patch would contain the fix across the source.  Thoughts?

I would appreciate creating two issues and use one only for reference
and link it by the one which contains patches and discussion if the
changes are large. Using SOLR- vs. LUCENE- I'd decide on a case by
case basis depending which "project" / "codebase" might undergo the
most significant changes. Generally,  referencing the issues in
CHANGES.TXT sounds like a good idea.

simon

On 8/18/10, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 18, 2010 at 10:48 AM, Grant Ingersoll <[EMAIL PROTECTED]>
> wrote:
>> Anyone have opinions on dealing with "combined issues" in JIRA.  By this,
>> I mean, issues that involve both changes to Lucene and Solr.
>
> It often makes sense - we've had a lot of patches that go across both
> already.
>
> -Yonik
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Wed, Aug 18, 2010 at 3:55 PM, Simon Willnauer <
[EMAIL PROTECTED]> wrote:

>
> I would appreciate creating two issues and use one only for reference
> and link it by the one which contains patches and discussion if the
> changes are large. Using SOLR- vs. LUCENE- I'd decide on a case by
> case basis depending which "project" / "codebase" might undergo the
> most significant changes. Generally,  referencing the issues in
> CHANGES.TXT sounds like a good idea.
>
>
I don't think this is realistic. often a patch needs to change lucene and
solr code in one commit.

Personally, i don't waste any time thinking about whether the issue is SOLR
or LUCENE, and I think two JIRAs is actually confusing.

--
Robert Muir
[EMAIL PROTECTED]

Form me it does not matter, but when I open new issues, I do it against the project where the “bug” is visible. If there is also code committed to Solr, but the main task is Lucene this is fine.

 

If we have a new functionality that affects both projects, you can create a secondary issue in the other project and link them.

 

Uwe

 

-----

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: [EMAIL PROTECTED]

 

From: Robert Muir [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 18, 2010 10:03 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Combined Lucene/Solr Issues

 

 

On Wed, Aug 18, 2010 at 3:55 PM, Simon Willnauer <[EMAIL PROTECTED]> wrote:

 

I would appreciate creating two issues and use one only for reference
and link it by the one which contains patches and discussion if the
changes are large. Using SOLR- vs. LUCENE- I'd decide on a case by
case basis depending which "project" / "codebase" might undergo the
most significant changes. Generally,  referencing the issues in
CHANGES.TXT sounds like a good idea.

 

I don't think this is realistic. often a patch needs to change lucene and solr code in one commit.

 

Personally, i don't waste any time thinking about whether the issue is SOLR or LUCENE, and I think two JIRAs is actually confusing.
--
Robert Muir
[EMAIL PROTECTED]

: Form me it does not matter, but when I open new issues, I do it against
: the project where the “bug” is visible. If there is also code committed
: to Solr, but the main task is Lucene this is fine.

Right ... i think it's handy to still have the "SOLR" bug queue for people
to file bugs against Solr, if they wind up requiring fixes further down
the tree then so be it.

: Personally, i don't waste any time thinking about whether the issue is
: SOLR or LUCENE, and I think two JIRAs is actually confusing.

If you know from the outset when you create an issue (ie: tracking an
improvement, or a new feature) that it requires updating "the whole tree"
then it should definitely be a LUCENE issue.  even if you aren't sure it
makes sense to start using LUCENE, but having SOLR arround for Solr users
to file bugs is handy.

Worst case scenerio: if it starts out as a SOLR issue and then the scope
gets bigger, creating a new LUCENE issue to track it (and linking the two)
seems trivial to me.

As far as refrencing LUCENE-* issues directly in Solr's CHANGES.txt --
sure, why not?

-Hoss

On Aug 19, 2010, at 2:14 PM, Chris Hostetter wrote:

> : Form me it does not matter, but when I open new issues, I do it against
> : the project where the “bug” is visible. If there is also code committed
> : to Solr, but the main task is Lucene this is fine.
>
> Right ... i think it's handy to still have the "SOLR" bug queue for people
> to file bugs against Solr, if they wind up requiring fixes further down
> the tree then so be it.

+1

>
> : Personally, i don't waste any time thinking about whether the issue is
> : SOLR or LUCENE, and I think two JIRAs is actually confusing.
>
> If you know from the outset when you create an issue (ie: tracking an
> improvement, or a new feature) that it requires updating "the whole tree"
> then it should definitely be a LUCENE issue.  even if you aren't sure it
> makes sense to start using LUCENE, but having SOLR arround for Solr users
> to file bugs is handy.

This is what I did for LUCENE-2608.  

>
> Worst case scenerio: if it starts out as a SOLR issue and then the scope
> gets bigger, creating a new LUCENE issue to track it (and linking the two)
> seems trivial to me.
>
> As far as refrencing LUCENE-* issues directly in Solr's CHANGES.txt --
> sure, why not?

Again, I did.

-Grant
---------------------------------------------------------------------

> Worst case scenerio: if it starts out as a SOLR issue and then the scope
> gets bigger, creating a new LUCENE issue to track it (and linking the two)
> seems trivial to me.

Thanks hoss for expressing what i tried to do :) That all makes perfect sense!

simon

On 8/19/10, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
>
> On Aug 19, 2010, at 2:14 PM, Chris Hostetter wrote:
>
>> : Form me it does not matter, but when I open new issues, I do it against
>> : the project where the “bug” is visible. If there is also code committed
>> : to Solr, but the main task is Lucene this is fine.
>>
>> Right ... i think it's handy to still have the "SOLR" bug queue for people
>>
>> to file bugs against Solr, if they wind up requiring fixes further down
>> the tree then so be it.
>
> +1
>
>>
>> : Personally, i don't waste any time thinking about whether the issue is
>> : SOLR or LUCENE, and I think two JIRAs is actually confusing.
>>
>> If you know from the outset when you create an issue (ie: tracking an
>> improvement, or a new feature) that it requires updating "the whole tree"
>> then it should definitely be a LUCENE issue.  even if you aren't sure it
>> makes sense to start using LUCENE, but having SOLR arround for Solr users
>> to file bugs is handy.
>
> This is what I did for LUCENE-2608.
>
>>
>> Worst case scenerio: if it starts out as a SOLR issue and then the scope
>> gets bigger, creating a new LUCENE issue to track it (and linking the two)
>>
>> seems trivial to me.
>>
>> As far as refrencing LUCENE-* issues directly in Solr's CHANGES.txt --
>> sure, why not?
>
> Again, I did.
>
> -Grant
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On Thu, Aug 19, 2010 at 6:25 PM, Simon Willnauer
<[EMAIL PROTECTED]> wrote:
>> Worst case scenerio: if it starts out as a SOLR issue and then the scope
>> gets bigger, creating a new LUCENE issue to track it (and linking the two)
>> seems trivial to me.
>
> Thanks hoss for expressing what i tried to do :) That all makes perfect sense!

This should not be mandated of course - it can still often make sense
for a single issue to cover changes to lucene and solr (and
lucene/solr modules).

-Yonik
http://www.lucidimagination.com

---------------------------------------------------------------------