Hi

Today we have separate JIRA projects for Lucene and Solr. This, IMO, starts
to become confusing and difficult to maintain. I'll explain:

* With modules, we now have components in the Lucene JIRA project for
different modules (some under modules/* some under lucene/contrib/*). Will
we have the same components duplication in the Solr JIRA project?

* Where do users go to open a bug report for a module - Lucene or Solr
projects? I'd hate to see that they open it under their "favorite" (or
worse. random picking) project. If so, it'll become a mess.

* Administration -- everything needs to be done twice. Create versions (same
one !) on both projects, close issues (after release) etc.

* Managing a release now means I should monitor two JIRA projects for the
3.2 (an example) version issues. Why?

I guess I'm not too sure what do two JIRA projects give us. Now that it is
the same project, why not make our (committers and contributors) life easier
by having one JIRA project w/ components:
lucene/core
lucene/contrib/<xyz>
modules/<xyz>
solr/core
solr/contrib/<xyz>
general/* (test, build)

It's already becoming confusing:
LUCENE-3097: post grouping faceting -- a great example for a module that
both Lucene and Solr users can use. Opened under Lucene project, and depends
on Solr issues (not a big deal)
LUCENE-3104: could easily have been opened under the Solr project. I don't
know why it was opened under Lucene (random maybe?)

Can we merge the two?

Shai

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 Conference
May 25-26, San Francisco
www.lucenerevolution.org
---------------------------------------------------------------------

> 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 think the two systems are fine -- not ideal, and they
should map (more or less) to where the entry should go in CHANGES.txt

ryan

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

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 the Solr users/community as a whole is use to the existence of the
SOLR project in Jira, and use to the SOLR-* issue naming convention, and
it would likely be more confusing for *them* to change now.

: * With modules, we now have components in the Lucene JIRA project for
: different modules (some under modules/* some under lucene/contrib/*). Will
: we have the same components duplication in the Solr JIRA project?

when we discussed this before, it seemed clear that top level modules
should be tracked as LUCENE issues, so i see no reason why there would be
duplications.

: * Where do users go to open a bug report for a module - Lucene or Solr
: projects? I'd hate to see that they open it under their "favorite" (or
: worse. random picking) project. If so, it'll become a mess.

the user bases tend to be very distinct -- if people are dealing with the
lucene java API directly they file a LUCENE bug, if they are dealing with
the Solr HTTP or client layer (SolrJ) APIs they file a Solr bug.

If an issue is filed in a place where we think it doesn't make sense, the
issue can easily be moved (and Jira does a redirect for anyone following
old links)

: * Administration -- everything needs to be done twice. Create versions (same
: one !) on both projects, close issues (after release) etc.

given the low overhead of this, it doesn't seem all that problematic.

: * Managing a release now means I should monitor two JIRA projects for the
: 3.2 (an example) version issues. Why?

Here's an example of a filter that shows you all issues marked to be fixed
in 3.2 in both projects...

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=%28project+%3D+SOLR+OR+project+%3D+LUCENE%29+AND+fixVersion+%3D+%223.2%22+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC%2C+key+DESC%2C+priority+DESC

: I guess I'm not too sure what do two JIRA projects give us. Now that it is
: the same project, why not make our (committers and contributors) life easier

Short answer: trade off "ease of use for committers + pain of
migration" against "ease of use for users" ... doesn't seem like a strong
need to change.

: It's already becoming confusing:

neither of these examples seem that confusing to me...

: LUCENE-3097: post grouping faceting -- a great example for a module that
: both Lucene and Solr users can use. Opened under Lucene project, and
: depends on Solr issues (not a big deal)

it's an issue for implementing a top level module, therforce it goes in
LUCENE.  it doesn't depend on any Solr issue, it's marked as being blocked
by another issue about adding another top level module

: LUCENE-3104: could easily have been opened under the Solr project. I
: don't know why it was opened under Lucene (random maybe?)

Because it's about improving the hudson build which operates at the top
level of the tree

-Hoss

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

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 also from a user expecations standpoint -- i
> think the Solr users/community as a whole is use to the existence of the
> SOLR project in Jira, and use to the SOLR-* issue naming convention, and
> it would likely be more confusing for *them* to change now.

+1

On Tue, May 17, 2011 at 9:23 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 distinct -- partly from a "pain of migration"
>> standpoint on our end, but also from a user expecations standpoint -- i
>> think the Solr users/community as a whole is use to the existence of the
>> SOLR project in Jira, and use to the SOLR-* issue naming convention, and
>> it would likely be more confusing for *them* to change now.

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 hard to stop that and make hard breaks that might hurt but
I think its the way to go. Drawn from what has happend in the last
weeks / month it would be good to start from the scratch at least in
JIRA. I'd go even further and nuke the name entirely and call
everything lucene - I know not many folks like the idea and it might
take a while to bake in but I think for us (PMC / Committers) and the
community it would be good. I am not calling a vote here just stating
my opinion.

here is my +1 to the JIRA suggestion

Simon
>
> +1
>
>
>

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

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
under solr/"?

I think that one day we will need to merge. The more modules we'll have, the
less issues will be open under Solr project (if it uses those modules). I
agree w/ what Simon wrote - users will get used to it, so that's not a good
reason IMO. Also, if we keep claiming the user base is different, then I
think we have a problem ... every Solr user is also a Lucene user
(eventually) -- true, some only interact w/ Solr REST API, and may not
know/care Lucene is run at the lower level. But for the community's sake, I
think merging JIRA will only help down the road.

Not very related to JIRA merge, but still ... if I look at Lucene project
today, I see ~30 issues marked for 3.2, so I think to myself "well, 3.2 in
maybe a month seems reasonable". But then I look at Solr project and see
~230 marked for 3.2 and I think "if we need to release both Lucene and Solr,
then we're definitely far from 3.2".

Now, I don't know if Solr's ~230 is just bad JIRA management, and most of
the issues are just drifted from version to version for several releases, or
Solr really has 230 issues that need to be addressed in 3.2, and then we
have a serious manpower.

I'm not saying that if the two were merged under the same project we'd have
*less* 3.2 issues overall for sure, but I have a feeling that would happen,
because at least for me, it's hard to track two projects and I usually look
@ Lucene. I can imagine that if they were merged under the same project, and
I'd see a longer list of issues, I'd do something (radical, like
closing/cleaning them :)). But I'm only guessing. Maybe I should try to run
w/ Hoss's query for some time and see if it affects my "itch" to reduce the
number of issues.

At the end of the day, I don't think we can maintain two projects for much
longer, and I don't think it's the right thing to do at all. And if one day
we'll merge JIRA projects, then tomorrow is as good a day as any other day.
Our users, I'm sure, will get used to it very quickly. I doubt users care
that much about the prefix SOLR-* for Solr issues.

Shai

On Wed, May 18, 2011 at 10:10 PM, Simon Willnauer <
[EMAIL PROTECTED]> wrote:

> On Tue, May 17, 2011 at 9:23 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 distinct -- partly from a "pain of migration"
> >> standpoint on our end, but also from a user expecations standpoint -- i
> >> think the Solr users/community as a whole is use to the existence of the
> >> SOLR project in Jira, and use to the SOLR-* issue naming convention, and
> >> it would likely be more confusing for *them* to change now.
>
> 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 hard to stop that and make hard breaks that might hurt but
> I think its the way to go. Drawn from what has happend in the last
> weeks / month it would be good to start from the scratch at least in
> JIRA. I'd go even further and nuke the name entirely and call
> everything lucene - I know not many folks like the idea and it might
> take a while to bake in but I think for us (PMC / Committers) and the
> community it would be good. I am not calling a vote here just stating
> my opinion.
>
> here is my +1 to the JIRA suggestion
>
> Simon
> >
> > +1
> >
> >
> >
>
> -----------------------

On Tue, May 17, 2011 at 10:23 PM, Steven A Rowe <[EMAIL PROTECTED]> 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 distinct -- partly from a "pain of migration"
> > standpoint on our end, but also from a user expecations standpoint -- i
> > think the Solr users/community as a whole is use to the existence of the
> > SOLR project in Jira, and use to the SOLR-* issue naming convention, and
> > it would likely be more confusing for *them* to change now.
>
> +1
>

+1 for keeping separate user lists and separate JIRA projects, stabilize, no
rush, release a few, then, perhaps, reiterate on this.

: 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
really simple with teh current version of Jira ... almost as easy as
changing "Component"

: I think that one day we will need to merge. The more modules we'll have, the
: less issues will be open under Solr project (if it uses those modules). I
: agree w/ what Simon wrote - users will get used to it, so that's not a good
: reason IMO. Also, if we keep claiming the user base is different, then I
: think we have a problem ... every Solr user is also a Lucene user
: (eventually) -- true, some only interact w/ Solr REST API, and may not
: know/care Lucene is run at the lower level. But for the community's sake, I
: think merging JIRA will only help down the road.

I just don't see it that way ... saying every Solr user is also a Lucene
user is like saying ever Solr user is a Java user, or every Solr user is a
commons-io user ... we don't expect our users to know even know that, let
alone assume that Solr users should know what layer of the stack a bug/feature
should be filed against.

If a Solr user has an issue/improvement at the Solr level of the stack
they file a SOLR issue -- if they are a savy dev and know that the only
real change is at the Lucene level they file a LUCENE issue, if we feel
like we need to move a SOLR issue to a LUCENE issue we can do so, if we
feel like there should be two issus to track the bug/change, one covering the
Solr layer changes and one covering some dependent Lucene layer change we
can do that to -- just like we could if someone filed a bug against a
module component and we decided there was a dependent, but fundementally
distinct core change that we wanted to track as a distinct jira.

: At the end of the day, I don't think we can maintain two projects for much
: longer, and I don't think it's the right thing to do at all. And if one day
: we'll merge JIRA projects, then tomorrow is as good a day as any other day.

We are one "Apache project", two "Apache Products".  The fact that the
Jira terminology is "Project" is an implementation detail.

If we get to the point where we decide that we want to release some
module as distinct release artifacts, because we think it has a distinct
user community who doesn't know/care about the Lucene Core as a whole,
then I would totally argue in favor of that module having a distinct Jira
Product/Project as well.
-Hoss

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

: 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 hard to stop that and make hard breaks that might hurt but

I just don't see how you think that would help anything ... we still need
to distinguish Jira issues to identify where in the "stack" they affect.

If there is a "divide" among the developers because of the niches where
they tend to work, will that divide magicly go away because we partition
all issues using the "component" feature of instead of by the Jira
"project" feature?

I don't really see how that makes any sense.  

Even if we all thought it did, and even if the cost/effort of
migrating/converting were totally free, the user bases (who interact with
the Solr APIs vs directly using the Lucene-Core/Module APIs) are so
distinct that I genuinely think sticking with distinct Jira "Projects"
makes more sense for our users.

: JIRA. I'd go even further and nuke the name entirely and call
: everything lucene - I know not many folks like the idea and it might
: take a while to bake in but I think for us (PMC / Committers) and the

"Everything" already is called Lucene ... the Project is "Apache Lucene"
the community is "Lucene" ... the Lucene project currently releases
several products, and one of them is called "Apache Solr" ... if you're
suggestion that we should ultimately elimianate the name "Solr" then we'd
still have to decide what we're going going to call that end product, the
artifact that we ship that provides the abstraction layer that Solr
currently provides.  

Even if you mean to suggest that we should only have one unified product
-- one singular release artifact -- that abstraction layer still needs a
name.  The name we have now is "Solr", it has brand awareness and a user
base who understands what it means to say they are "Installing Solr" or
that a new feature is available when "Using Solr"

Eliminating that name doesn't seem like it would benefit the user
community in anyway.

-Hoss

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

+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 <[EMAIL PROTECTED]> 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
> : with what we work on. It feels like we don't do that today and we
> : should work hard to stop that and make hard breaks that might hurt but
>
> I just don't see how you think that would help anything ... we still need
> to distinguish Jira issues to identify where in the "stack" they affect.
>
> If there is a "divide" among the developers because of the niches where
> they tend to work, will that divide magicly go away because we partition
> all issues using the "component" feature of instead of by the Jira
> "project" feature?
>
> I don't really see how that makes any sense.
>
> Even if we all thought it did, and even if the cost/effort of
> migrating/converting were totally free, the user bases (who interact with
> the Solr APIs vs directly using the Lucene-Core/Module APIs) are so
> distinct that I genuinely think sticking with distinct Jira "Projects"
> makes more sense for our users.
>
> : JIRA. I'd go even further and nuke the name entirely and call
> : everything lucene - I know not many folks like the idea and it might
> : take a while to bake in but I think for us (PMC / Committers) and the
>
> "Everything" already is called Lucene ... the Project is "Apache Lucene"
> the community is "Lucene" ... the Lucene project currently releases
> several products, and one of them is called "Apache Solr" ... if you're
> suggestion that we should ultimately elimianate the name "Solr" then we'd
> still have to decide what we're going going to call that end product, the
> artifact that we ship that provides the abstraction layer that Solr
> currently provides.
>
> Even if you mean to suggest that we should only have one unified product
> -- one singular release artifact -- that abstraction layer still needs a
> name.  The name we have now is "Solr", it has brand awareness and a user
> base who understands what it means to say they are "Installing Solr" or
> that a new feature is available when "Using Solr"
>
> Eliminating that name doesn't seem like it would benefit the user
> community in anyway.
>
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Kirill Zakharenko/Кирилл Захаренко
E-Mail/Jabber: [EMAIL PROTECTED]
Phone: +7 (495) 683-567-4
ICQ: 104465785

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

On Wed, May 18, 2011 at 10:53 PM, Chris Hostetter
<[EMAIL PROTECTED]> 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
> : with what we work on. It feels like we don't do that today and we
> : should work hard to stop that and make hard breaks that might hurt but
>
> I just don't see how you think that would help anything ... we still need
> to distinguish Jira issues to identify where in the "stack" they affect.
>
> If there is a "divide" among the developers because of the niches where
> they tend to work, will that divide magicly go away because we partition
> all issues using the "component" feature of instead of by the Jira
> "project" feature?
>
> I don't really see how that makes any sense.
>
> Even if we all thought it did, and even if the cost/effort of
> migrating/converting were totally free, the user bases (who interact with
> the Solr APIs vs directly using the Lucene-Core/Module APIs) are so
> distinct that I genuinely think sticking with distinct Jira "Projects"
> makes more sense for our users.
>
> : JIRA. I'd go even further and nuke the name entirely and call
> : everything lucene - I know not many folks like the idea and it might
> : take a while to bake in but I think for us (PMC / Committers) and the
>
> "Everything" already is called Lucene ... the Project is "Apache Lucene"
> the community is "Lucene" ... the Lucene project currently releases
> several products, and one of them is called "Apache Solr" ... if you're
> suggestion that we should ultimately elimianate the name "Solr" then we'd
> still have to decide what we're going going to call that end product, the
> artifact that we ship that provides the abstraction layer that Solr
> currently provides.
>
> Even if you mean to suggest that we should only have one unified product
> -- one singular release artifact -- that abstraction layer still needs a
> name.  The name we have now is "Solr", it has brand awareness and a user
> base who understands what it means to say they are "Installing Solr" or
> that a new feature is available when "Using Solr"
>
> Eliminating that name doesn't seem like it would benefit the user
> community in anyway.

What I was saying / trying to say is that we as the community should
move closer together.
In all our minds, especially in the users mind Solr is a Project and
Lucene is a Project. If we'd start over I would propose something like
Lucene-httpd or something similar. But don't get me wrong I just went
one step further than Shai since I think his idea made sense. I don't
think all that would be a big issue to users - they use the http
interface and they don't give a shit if its called solr or not.

For us I think it makes a big difference. In our minds though. I agree
with you that solr is a product and lucene is the project but we
should enforce this. Like all namespaces say o.a.solr not
o.a.lucene.solr so it implies we are two projects which is not true. I
am not sure how we should proceed here but to change our minds we must
change facts. Just my opinion.

simon
>
>
>
> -Hoss
>

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