Due to a tremendous amount of work by our newly merged committer
corps, the get-on-lucene-trunk branch (branches/solr) is ready for
prime-time as the new solr trunk!  Lucene and Solr need to move to a
common trunk for a host of reasons, including single patches that can
cover both, shared tags and branches, and shared test code w/o a test
jar.

The current Lucene trunk is: .../lucene/java/trunk
The current Solr trunk is: .../lucene/solr/trunk

So, we have a few options on where to put Solr's new trunk:

Lucene moves to Solr's trunk:
  /solr/trunk, /solr/trunk/lucene

Solr moves to Lucene's trunk:
  /java/trunk, /java/trunk/solr

Both projects move to a new trunk:
  /something/trunk/java, /something/trunk/solr

-Yonik

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

On 03/15/2010 11:28 PM, Yonik Seeley wrote:
> So, we have a few options on where to put Solr's new trunk:
>
>
> Solr moves to Lucene's trunk:
>    /java/trunk, /java/trunk/sol
+1. With the goal of merged dev, merged tests, this looks the best to
me. Simple to do patches that span both, simple to setup
Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.

--
- Mark

http://www.lucidimagination.com
---------------------------------------------------------------------

On Mon, Mar 15, 2010 at 11:41 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
>>
>> Solr moves to Lucene's trunk:
>>   /java/trunk, /java/trunk/sol
>
> +1. With the goal of merged dev, merged tests, this looks the best to me.
> Simple to do patches that span both, simple to setup
> Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it.
>

+1

--
Robert Muir
[EMAIL PROTECTED]

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

: prime-time as the new solr trunk!  Lucene and Solr need to move to a
: common trunk for a host of reasons, including single patches that can
: cover both, shared tags and branches, and shared test code w/o a test
: jar.

Without a clearer picture of how people envision development "overhead"
working as we move forward, it's really hard to understand how any of
these ideas make sense...
  1) how should hte automated build process(es) work?
  2) how are we going to do branching/tagging for releases?  particularly
in situations where one product is ready for a rlease and hte other isn't?
  3) how are we going to deal with mino bug fix release tagging?
  4) should it be possible for people to check out Lucene-Java w/o
checking out Solr?

(i suspect a whole lot of people who only care about the core library are
going to really adamantly not want to have to check out all of Solr just
to work on the core)

: Both projects move to a new trunk:
:   /something/trunk/java, /something/trunk/solr

by gut says something like this will more the most sense, assuming
"/something/trunk" == "/java/trunk" and "java" actually means "core" ...
ie: this discussion should really be part and parcel with how contribs
should be reorged.

-Hoss
---------------------------------------------------------------------

Hi all,

I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:

> : prime-time as the new solr trunk!  Lucene and Solr need to move to a
> : common trunk for a host of reasons, including single patches that can
> : cover both, shared tags and branches, and shared test code w/o a test
> : jar.
>
> Without a clearer picture of how people envision development "overhead"
> working as we move forward, it's really hard to understand how any of
> these ideas make sense...
>   1) how should hte automated build process(es) work?
>   2) how are we going to do branching/tagging for releases?
> particularly
> in situations where one product is ready for a rlease and hte other
> isn't?
>   3) how are we going to deal with mino bug fix release tagging?
>   4) should it be possible for people to check out Lucene-Java w/o
> checking out Solr?

That are important questions and not simply to solve!

> (i suspect a whole lot of people who only care about the core library
> are
> going to really adamantly not want to have to check out all of Solr
> just
> to work on the core)

Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.

> : Both projects move to a new trunk:
> :   /something/trunk/java, /something/trunk/solr

This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.

The problems of this approach far overweigh the positive side:

In the original vote, we said, Lucene can release without Solr:
Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.

If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.

I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.

And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.

So: If merge, keep both on Java 1.5 !!!

> by gut says something like this will more the most sense, assuming
> "/something/trunk" == "/java/trunk" and "java" actually means "core"
> ...

And that is how it looks currently and I am fine with it!

> ie: this discussion should really be part and parcel with how contribs
> should be reorged.

That is exactly what should be done. Not now simply copy the folders somewhere for some "development simplification" that not really is one and opens more problems!

I propose another idea for now until the "module" decision is [DISCUSS]ed and [VOTE]d:

Lets create a new project folder with trunk and branches for combined trunk development in SVN (this can be later the folder for the module development). This folder simply contains a delegating build.xml (delegating the common tasks like build and test and so on to solr and trunk).The folder simply uses svn:external SVN props to link current solr and lucene trunk as subfolders. So developers that want to work on both can simply checkout this folder and SVN will resolve the externals. As this is trunk development, the externals will be without rev numbers and relative for the http(s) problem (SVN 1.5+ required).

For testing flex, we create a branch of this folder, still pointing to solr-trunk, but flex branch in Lucene.

One task of the main build.xml would be to copy all produced JAR files of Lucene into the correct build folder in Solr.

I hope that you all understand me, but I am against merging trunks (for now) until we have a clear module decision.

Uwe

On Tue, Mar 16, 2010 at 8:18 AM, Uwe Schindler <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:
>
>> : prime-time as the new solr trunk!  Lucene and Solr need to move to a
>> : common trunk for a host of reasons, including single patches that can
>> : cover both, shared tags and branches, and shared test code w/o a test
>> : jar.
>>
>> Without a clearer picture of how people envision development "overhead"
>> working as we move forward, it's really hard to understand how any of
>> these ideas make sense...
>>   1) how should hte automated build process(es) work?
>>   2) how are we going to do branching/tagging for releases?
>> particularly
>> in situations where one product is ready for a rlease and hte other
>> isn't?
>>   3) how are we going to deal with mino bug fix release tagging?
>>   4) should it be possible for people to check out Lucene-Java w/o
>> checking out Solr?
>
> That are important questions and not simply to solve!
>
>> (i suspect a whole lot of people who only care about the core library
>> are
>> going to really adamantly not want to have to check out all of Solr
>> just
>> to work on the core)
>
> Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.
>
>> : Both projects move to a new trunk:
>> :   /something/trunk/java, /something/trunk/solr
>
> This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.
>
> The problems of this approach far overweigh the positive side:
>
> In the original vote, we said, Lucene can release without Solr:
> Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.
>
> If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.
>
> I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.
>
> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.
>
> So: If merge, keep both on Java 1.5 !!!
>
>> by gut says something like this will more the most sense, assuming
>> "/something/trunk" == "/java/trunk" and "java" actually means "core"
>> ...
>
> And that is how it looks currently and I am fine with it!
>
>> ie: this discussion should really be part and parcel with how contribs

+1 - as I recall correctly that is what uwe and I proposed initially
on IRC when solr got copied initially. This makes a lot of sense as it
does not break anybodies checkouts and enables all "Solcene"
developers to move on. From a Lucene point of view Lucene should not
see any Solr below its root as we do not have dependencies on it,
letting them live side by side seems to be the way to go as uwe says.

One more thing which I wonder about even more is that this whole
merging happens so quickly for reasons I don't see right now. I don't
want to keep anybody from making progress but it appears like a rush
to me. Committers, start copying stuff around without discussion or
having a jira issue (sry mark :) - not blaming you personally),
discussions on the list are extremely short living and several people
seem to be rushed somehow.
I can understand the moving forward is tempting but based on all this
discussion during the "vote" could we move a little slower and little
more relaxed to figure out the right solutions.

If my impression should be wrong or if I miss something please ignore
the last paragraph.

BTW: I still have the impression that if I don't follow IRC constantly
I'm missing important things.

simon

I completely agree with Uwe and Hoss.  These questions need to be
addressed first.

I still want to be able to only checkout Lucene code and run the Lucene
build independently from Solr.  And Lucene needs to be able to release
without Solr and the branching/tagging needs to support that as Uwe
points out.

  Michael

On 3/16/10 12:18 AM, Uwe Schindler wrote:
> Hi all,
>
> I don't want to be against all other developers that voted +1 for the SVN "merge", but I am not happy with it. Most importantly for the reasons Hoss mentioned:
>
>    
>> : prime-time as the new solr trunk!  Lucene and Solr need to move to a
>> : common trunk for a host of reasons, including single patches that can
>> : cover both, shared tags and branches, and shared test code w/o a test
>> : jar.
>>
>> Without a clearer picture of how people envision development "overhead"
>> working as we move forward, it's really hard to understand how any of
>> these ideas make sense...
>>    1) how should hte automated build process(es) work?
>>    2) how are we going to do branching/tagging for releases?
>> particularly
>> in situations where one product is ready for a rlease and hte other
>> isn't?
>>    3) how are we going to deal with mino bug fix release tagging?
>>    4) should it be possible for people to check out Lucene-Java w/o
>> checking out Solr?
>>      
> That are important questions and not simply to solve!
>
>    
>> (i suspect a whole lot of people who only care about the core library
>> are
>> going to really adamantly not want to have to check out all of Solr
>> just
>> to work on the core)
>>      
> Exactly! The Solr checkout is really huge because of thousands of JAR files and so on. The badest thing we could do would be to merge all those JARs into one general lib folder or like so. Please do not! Lucene-core should stay a lib without any external deps.
>
>    
>> : Both projects move to a new trunk:
>> :   /something/trunk/java, /something/trunk/solr
>>      
> This would be the only optinon we have. This new folder could simply contain two dirs below and a build.xml in the top level that delegates and builds first lucene, then solr. But you can do this also with separate checkouts and a simple script downloaded from the wiki.
>
> The problems of this approach far overweigh the positive side:
>
> In the original vote, we said, Lucene can release without Solr:
> Releasing (I was the last release mangaer) contains things like creating branches and tags. In SVN, if you create a branch, you copy everything from under trunk (or another branch) to a new folder below branches (for tags under tags). "tags" on most SVN servers has an additional limittation, that it is not possible to change anything under "tags" except copying.
>
> If we have those combined trunk folder and Lucene wants to release and creates a branch/tag. Solr is enforced to do this too. OK, you could say, we just branch the folder lucene and let solr where it is. But that would be a against conventions and the branch checkout could not life alone.
>
> I just repeat: we wanted to merge devs and not codebase! And merging devs is a "code change" clearly.
>
> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler, where Solr seems to be on 1.6 since yesterday? (Yonik added something to common-build.xml). On my development system I have no Java 1.6 installed at all as default build, I ever use Java 1.5 for building Lucene. If we merge that and have both on different JVMs the same problems like with 1.4/1.5 start. Developers use 1.6 methods because their compiler does not warn them. So everybody working on Lucene should at least have Java 1.5 compiler and try to compile his changes before committing. I do this (as I use 1.5 for developing), 1.6 on some of our servers.

On 3/16/10 12:43 AM, Simon Willnauer wrote:
> If my impression should be wrong or if I miss something please ignore
> the last paragraph.
>    

I feel exactly like you, Simon.  I don't understand the rush.  Also,
we're in review-and-commit process, not commit-and-review.  Changes have
to be proposed, discussed and ideally attached to jira as patches first.

> BTW: I still have the impression that if I don't follow IRC constantly
> I'm missing important things.
>
>    
Me too.  I don't have the time to follow IRC in addition to jira and
mailinglists.  I know I've been missing stuff, because in the past I
commented on jira issues and later was told that my questions were
already discussed thoroughly on IRC.  I've also seen jira issues that
start with something like "Summary of IRC discussion:".

  Michael

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

Hi,

> And Lucene is on Java 1.5 and should be compiled with an 1.5 compiler,
> where Solr seems to be on 1.6 since yesterday? (Yonik added something
> to common-build.xml). On my development system I have no Java 1.6
> installed at all as default build, I ever use Java 1.5 for building
> Lucene. If we merge that and have both on different JVMs the same
> problems like with 1.4/1.5 start. Developers use 1.6 methods because
> their compiler does not warn them. So everybody working on Lucene
> should at least have Java 1.5 compiler and try to compile his changes
> before committing. I do this (as I use 1.5 for developing), 1.6 on some
> of our servers.
>
> So: If merge, keep both on Java 1.5 !!!

I changed common-build.xml in the new solr branch to Java 1.5 again, as there is currently no reason to change this and especially as it was not discussed anywhere.

Java 1.5 as base for both solr and lucene is better and the few features of Java 1.6 does not rectify to move up. I have my development area configured with Java 1.5 and I only develop Lucene in 1.5. I am then sure to not use the wrong methods when creating patches. You can still tell users to run with JRE 1.6, but development should stay on 1.5 for now.

Uwe
---------------------------------------------------------------------

On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <[EMAIL PROTECTED]> wrote:
> On 3/16/10 12:43 AM, Simon Willnauer wrote:
>>
>> If my impression should be wrong or if I miss something please ignore
>> the last paragraph.
>
> I feel exactly like you, Simon.  I don't understand the rush.  Also, we're
> in review-and-commit process, not commit-and-review.  Changes have to be
> proposed, discussed and ideally attached to jira as patches first.

There's obviously alot of excitement driving the progress here, and
there's been awesome progress.  Things are moving fast, but...

Remember that all commits/fast iterations are being done on a branch,
so that people involved can make fast progress.

When we land that branch onto trunk, there will be the usual scrutiny
("review then commit") of the changes that're going in, and this email
was started to get the most important topic ("where does all this
land, anyway") going, first.

EG changes like a move to Java 1.6, disallowing compression in Solr's
schema.xml, the Version changes percolating into Solr, all obviously
need sizable review & discussion...

>> BTW: I still have the impression that if I don't follow IRC constantly
>> I'm missing important things.
>
> Me too.  I don't have the time to follow IRC in addition to jira and
> mailinglists.  I know I've been missing stuff, because in the past I
> commented on jira issues and later was told that my questions were already
> discussed thoroughly on IRC.  I've also seen jira issues that start with
> something like "Summary of IRC discussion:".

This is a hard problem...

IRC is a very good tool to enable those that have the time (and I
agree it's ALOT OF TIME -- I can't keep up with it either) to work
together.  Fast design discussions are a powerful way to bat around
random ideas, and I'd say IRC has already produced a number of good
ideas for improving Lucene (opened as issues, lately...).

But the thing to remember is of all the crazy discussions that happen
on IRC (and there are MANY that don't pan out), when a "real" idea
pans out, it must then go through the normal process -- turn into an
issue, comments are added summarizing the pros/cons that were
discussed on IRC, a patch is created and must be reviewed, iterated,
and then committed.  The CTR process is still intact... it's just that
IRC is a faster way for some devs to discuss things that may turn into
real ideas (or, may get dropped on the floor).

Does anyone know how other projects fold in IRC...?

Mike

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

On 03/16/2010 03:43 AM, Simon Willnauer wrote:
>
> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
>    

Meh - I think your just plain wrong about this. Anyone can work as fast
as they want on anything. Nothing has happened faster than the community
wants yet. Your too concerned. This is called discussion. Nothing has
happened. In my opinion, the whole freak out of what goes where in svn
was so over blown - its so easy to move this stuff around at the drop of
a hat. That's why it was suggested we put a branch there and no one saw
anything wrong it with for the moment - everyone said, well we can just
easily move it if someone has an issue - which we did. Didn't expect the
freak out though. Frankly, we were just seeking a branch really, and
didn't care where it went.

Some of us are anxious to do some work - some of us are anxious to merge
some code - no one is forcing this stuff on the others at a rapid pace -
everyone gets there say as always. This is why we wanted a branch we
could committ what we wanted to. SVN locations make starting the merge
of code easier. They are easy to change. This is not like rushing index
format changes. Its src code location - it can be moved at the drop of
the hat. The sooner we resolve what we are going to do, the sooner we
can start getting more work done that we hoped to get down with this
merge. This thread starts that discussion. You can't start a discussion
to early. Perhaps it leads to another discussion first, but their is no
such thing as rushing the start of discussion. It doesn't say "figure it
out by tomorrow, cause we are doing this tomorrow. " It doesn't say,
figure this out by next week, because we are doing this next week. It
says lets discuss where this is going to go.

I think some people just need to relax, and discuss what they would like
to see and worry less about how fast others are working. Fast work is
good. It means more work. Nothing is going to happen until the community
figures things out.

> BTW: I still have the impression that if I don't follow IRC constantly
> I'm missing important things.
>    
That's your impression then. Follow IRC if you want. People talk all
over the places about Lucen/Solr - many times in places you can't follow
- if it didn't happen on the list, it didn't happen. Michael Busch
follows up saying, "people say it was discussed thoroughly on IRC" - so
what? It doesn't count as a valid point of reference - I haven't seen
that, but you can just tell someone that says that so - they owe you an
explanation.
--
- Mark

http://www.lucidimagination.com
---------------------------------------------------------------------

I think it like the 1st option best (lucene moves as subdir to solr's
current trunk SVN path), but I don't feel strongly.

This'd mean one could simply checkout lucene alone and do everything
you can do today.

But if you check out solr, you also get a full checkout of lucene, and
solr's build.xml will go and build lucene, copy over its jars to its
lib folder, and then do everything it currently does.

I think?

This small step is not much change over what we have today -- the code
simply moves, unchanged, except for some fixes to solr's build.xml to
go and build its lucene subdir first.

The bigger stuff, ideas on modules like renaming contrib->modules,
consolidating all analyzers, queries, queryparsers, highlighters, all
comes later.

Mike

On Mon, Mar 15, 2010 at 10:28 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Due to a tremendous amount of work by our newly merged committer
> corps, the get-on-lucene-trunk branch (branches/solr) is ready for
> prime-time as the new solr trunk!  Lucene and Solr need to move to a
> common trunk for a host of reasons, including single patches that can
> cover both, shared tags and branches, and shared test code w/o a test
> jar.
>
> The current Lucene trunk is: .../lucene/java/trunk
> The current Solr trunk is: .../lucene/solr/trunk
>
> So, we have a few options on where to put Solr's new trunk:
>
> Lucene moves to Solr's trunk:
>  /solr/trunk, /solr/trunk/lucene
>
> Solr moves to Lucene's trunk:
>  /java/trunk, /java/trunk/solr
>
> Both projects move to a new trunk:
>  /something/trunk/java, /something/trunk/solr
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

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

On Tue, Mar 16, 2010 at 3:44 PM, Mark Miller <[EMAIL PROTECTED]> wrote:

> On 03/16/2010 03:43 AM, Simon Willnauer wrote:
>
>>
>> One more thing which I wonder about even more is that this whole
>> merging happens so quickly for reasons I don't see right now. I don't
>> want to keep anybody from making progress but it appears like a rush
>> to me.
>>
>>
>
> Meh - I think your just plain wrong about this. Anyone can work as fast as
> they want on anything. Nothing has happened faster than the community wants
> yet. Your too concerned. This is called discussion. Nothing has happened. In
> my opinion, the whole freak out of what goes where in svn was so over blown
> - its so easy to move this stuff around at the drop of a hat. That's why it
> was suggested we put a branch there and no one saw anything wrong it with
> for the moment - everyone said, well we can just easily move it if someone
> has an issue - which we did. Didn't expect the freak out though. Frankly, we
> were just seeking a branch really, and didn't care where it went.
>
> Some of us are anxious to do some work - some of us are anxious to merge
> some code - no one is forcing this stuff on the others at a rapid pace -
> everyone gets there say as always. This is why we wanted a branch we could
> committ what we wanted to. SVN locations make starting the merge of code
> easier. They are easy to change. This is not like rushing index format
> changes. Its src code location - it can be moved at the drop of the hat. The
> sooner we resolve what we are going to do, the sooner we can start getting
> more work done that we hoped to get down with this merge. This thread starts
> that discussion. You can't start a discussion to early. Perhaps it leads to
> another discussion first, but their is no such thing as rushing the start of
> discussion. It doesn't say "figure it out by tomorrow, cause we are doing
> this tomorrow. " It doesn't say, figure this out by next week, because we
> are doing this next week. It says lets discuss where this is going to go.
>
> I think some people just need to relax, and discuss what they would like to
> see and worry less about how fast others are working. Fast work is good. It
> means more work. Nothing is going to happen until the community figures
> things out.
>
>

>  BTW: I still have the impression that if I don't follow IRC constantly
>> I'm missing important things.
>>
>>
> That's your impression then. Follow IRC if you want. People talk all over
> the places about Lucen/Solr - many times in places you can't follow - if it
> didn't happen on the list, it didn't happen. Michael Busch follows up
> saying, "people say it was discussed thoroughly on IRC" - so what? It
> doesn't count as a valid point of reference - I haven't seen that, but you
> can just tell someone that says that so - they owe you an explanation.
>
>
Wow, you guys are moving fast! Thats a good thing.

IRC is fine if you want to discuss something quickly. But it has its
limitations. For example, I cannot follow IRC most of the times because I'm
in a different time zone. But I don't want to stop anyone either. In fact, I
can't do that. Nobody can.

All I want to say is that once discussions have happened and a plan agreed
upon, it may be a good idea to let solr-dev/java-dev know the plan. In this
case I didn't know a new branch was created until I saw was a commit
notification and then Yonik's email.

--
Regards,
Shalin Shekhar Mangar.

On 03/16/2010 07:05 AM, Shalin Shekhar Mangar wrote:
>
> Wow, you guys are moving fast! Thats a good thing.
>
> IRC is fine if you want to discuss something quickly. But it has its
> limitations. For example, I cannot follow IRC most of the times
> because I'm in a different time zone. But I don't want to stop anyone
> either. In fact, I can't do that. Nobody can.
>
> All I want to say is that once discussions have happened and a plan
> agreed upon, it may be a good idea to let solr-dev/java-dev know the
> plan. In this case I didn't know a new branch was created until I saw
> was a commit notification and then Yonik's email.
>

Hi Shalin - I like your attitude ;)

-

Yonik's email was the notification of the plan :) Though we had no plan.
When Robert and I made the branch we had no plan really - we just needed
a place to put together our patches and do the final work. We were
trying to do it with patches, but it was becoming difficult. But when we
started we had no real plan - just to see if we could get Solr up and
running on Lucene 3.01 and then trunk. Anything beyond that, we have not
planned for - and before that was even completed, there were emails to
java-dev about it. But we conceived nothing beyond seeing if we could
get Solr running on the latest Lucene.

 From our perspective, we would have been just as happy with a branch on
my local hard drive! That would have taken longer to setup though.

--
- Mark

http://www.lucidimagination.com
---------------------------------------------------------------------

On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
<[EMAIL PROTECTED]> wrote:

> One more thing which I wonder about even more is that this whole
> merging happens so quickly for reasons I don't see right now. I don't
> want to keep anybody from making progress but it appears like a rush
> to me.
By the way, the serious changes we applied to the branch, most of them
have been sitting in JIRA over 3 months not doing much: SOLR-1659

if you follow the linked issues, you can see all the stuff that got
put in the branch... the branch was helpful for me, as I could help
Mark with the "ton of little things", like TokenStreams embedded
inside JSP files :)

As its just a branch, if you want to go look at those patches
(especially anything I did) and provide technical feedback, that would
be great!

But I think its a mistake to say things are rushed when the work has
been done for months.

--
Robert Muir
[EMAIL PROTECTED]

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

On Mar 16, 2010, at 3:51 AM, Michael Busch wrote:

> On 3/16/10 12:43 AM, Simon Willnauer wrote:Me too.  I don't have the time to follow IRC in addition to jira and mailinglists.  I know I've been missing stuff, because in the past I commented on jira issues and later was told that my questions were already discussed thoroughly on IRC.  I've also seen jira issues that start with something like "Summary of IRC discussion:".

I too am troubled by the likes of this and have been feeling much the same way, as many already know.  It is on my list of things to discuss with the community, but I was going to wait a week or so to send, to let the volume die down a bit.

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

My snap impression is that moving lucene to a sub-tree
under SOLR would introduce some confusion in the minds
of new folks looking at the code. *We* all know that Lucene
stands by itself, but putting it under a solr makes that less
obvious. I claim that there would be questions like "so can
I just use Lucene without SOLR?".

That said, the questions about release management, branching,
tagging, etc. take complete precedence over minor
confusion when the answer is "just go to directory X and
checkout if you want Lucene only".

FWIW
Erick

On Tue, Mar 16, 2010 at 8:30 AM, Robert Muir <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
> <[EMAIL PROTECTED]> wrote:
>
> > One more thing which I wonder about even more is that this whole
> > merging happens so quickly for reasons I don't see right now. I don't
> > want to keep anybody from making progress but it appears like a rush
> > to me.
>
>
> By the way, the serious changes we applied to the branch, most of them
> have been sitting in JIRA over 3 months not doing much: SOLR-1659
>
> if you follow the linked issues, you can see all the stuff that got
> put in the branch... the branch was helpful for me, as I could help
> Mark with the "ton of little things", like TokenStreams embedded
> inside JSP files :)
>
> As its just a branch, if you want to go look at those patches
> (especially anything I did) and provide technical feedback, that would
> be great!
>
> But I think its a mistake to say things are rushed when the work has
> been done for months.
>
> --
> Robert Muir
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

On 2010-03-16 12:29, Mark Miller wrote:

>  From our perspective, we would have been just as happy with a branch on
> my local hard drive! That would have taken longer to setup though.

You could have used git instead. There is a good integration between git
and svn, and it's much easier (a giant understatement...) to handle
branching and merging in git, both between git branches and syncing with
external svn.

--
Best regards,
Andrzej Bialecki     <><
  ___. ___ ___ ___ _ _   __________________________________
[__ || __|__/|__||\/|  Information Retrieval, Semantic Web
___|||__||  \|  ||  |  Embedded Unix, System Integration
http://www.sigram.com  Contact: info at sigram dot com
---------------------------------------------------------------------

On 03/16/2010 09:05 AM, Andrzej Bialecki wrote:
> On 2010-03-16 12:29, Mark Miller wrote:
>
>>  From our perspective, we would have been just as happy with a branch on
>> my local hard drive! That would have taken longer to setup though.
>
> You could have used git instead. There is a good integration between
> git and svn, and it's much easier (a giant understatement...) to
> handle branching and merging in git, both between git branches and
> syncing with external svn.
>
Yeah, we have actually discussed doing things like GIT in the past -
prob main reason we didn't is learning curve at the moment. I haven't
used it yet.

--
- Mark

http://www.lucidimagination.com
---------------------------------------------------------------------

On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <[EMAIL PROTECTED]> wrote:
> Also, we're in review-and-commit process, not commit-and-review.  Changes have to be
> proposed, discussed and ideally attached to jira as patches first.

Correction, just for the sake of avoiding future confusion (i.e. I'm
not making any point about this thread):

Lucene and Solr have always officially been CTR.
For trunk, we normally use a bit of informal lazy consensus for
anything big, hard, or that might be controvertial... but we are not
officially RTC.

-Yonik

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

On 03/16/2010 10:09 AM, Yonik Seeley wrote:
> On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch<[EMAIL PROTECTED]>  wrote:
>    
>> Also, we're in review-and-commit process, not commit-and-review.  Changes have to be
>> proposed, discussed and ideally attached to jira as patches first.
>>      
> Correction, just for the sake of avoiding future confusion (i.e. I'm
> not making any point about this thread):
>
> Lucene and Solr have always officially been CTR.
> For trunk, we normally use a bit of informal lazy consensus for
> anything big, hard, or that might be controvertial... but we are not
> officially RTC.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>    

In any case, this is a branch. People really want to enforce RTC on a
branch??? Even if that was our official process on trunk (which I agree
it has not been) that's not how the flex branch worked. That's not how
the solr_cloud branch worked. That's not how other previous branches
have worked.

IMO - anyone should be able to create a branch for anything - to play
around with whatever they want. We should encourage this. Branches are
good. And they take up little space.
Branch changes have to be proposed, discussed, and attached to JIRA?
Uggg - I certainly hope not.

Branches should be considered replacements for huge unwieldy patches. Do
I have to propose and discuss before I put up a patch?

--
- Mark

http://www.lucidimagination.com
---------------------------------------------------------------------

On Tue, Mar 16, 2010 at 5:42 AM, Michael McCandless
<lucene@mikemccandless.com> wrote:
> I think it like the 1st option best (lucene moves as subdir to solr's
> current trunk SVN path), but I don't feel strongly.
>
> This'd mean one could simply checkout lucene alone and do everything
> you can do today.
>
> But if you check out solr, you also get a full checkout of lucene, and
> solr's build.xml will go and build lucene, copy over its jars to its
> lib folder, and then do everything it currently does.
>
> I think?
>
> This small step is not much change over what we have today -- the code
> simply moves, unchanged, except for some fixes to solr's build.xml to
> go and build its lucene subdir first.

Huh - I was leaning more toward putting solr under lucene because I
thought that might be more acceptable to the lucene folks (actually,
now lucene/solr folks) than vice-versa.

But your points make perfect sense.

> The bigger stuff, ideas on modules like renaming contrib->modules,
> consolidating all analyzers, queries, queryparsers, highlighters, all
> comes later.

+1

-Yonik

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

On Mar 16, 2010, at 10:18 AM, Mark Miller wrote:

> On 03/16/2010 10:09 AM, Yonik Seeley wrote:
>> On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch<[EMAIL PROTECTED]>  wrote:
>>
>>> Also, we're in review-and-commit process, not commit-and-review.  Changes have to be
>>> proposed, discussed and ideally attached to jira as patches first.
>>>
>> Correction, just for the sake of avoiding future confusion (i.e. I'm
>> not making any point about this thread):
>>
>> Lucene and Solr have always officially been CTR.
>> For trunk, we normally use a bit of informal lazy consensus for
>> anything big, hard, or that might be controvertial... but we are not
>> officially RTC.
>>
>> -Yonik
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>
> In any case, this is a branch. People really want to enforce RTC on a branch??? Even if that was our official process on trunk (which I agree it has not been) that's not how the flex branch worked. That's not how the solr_cloud branch worked. That's not how other previous branches have worked.
>
> IMO - anyone should be able to create a branch for anything - to play around with whatever they want. We should encourage this. Branches are good. And they take up little space.
>

+1.  Furthermore, it is incumbent on the people working on the branch to then present and discuss when/how to merge to trunk, just like any big patch.
---------------------------------------------------------------------

Hi

My only concern w/ how SVN might end up organized is that I'll still be able
checkout core lucene independently of Solr (and possibly contrib/modules)
and then build and test it. Also a separate project in Eclipse is important
as well.

How about this structure:
<root>/solr/trunk
<root>/lucene/trunk
<root>/modules/trunk

<root> can be left out if we don't think it's necessary.

This should allow us to:
1) Release each and everyone of them independently
2) Introduce dependencies between modules -> lucene and Solr -> modules +
lucene as, IMO, it should be. Lucene is core, modules extends it and Solr
extends and uses both.
3) Allow one to checkout exactly what it needs to work on.
4) Modules will always depend on a certain lucene version, either a cut
release or trunk. When it's released, its build.xml will be changed as part
of the release process to point to the lucene release (not trunk!) it
supports and depends on.
5) Same for Solr.

When a patch for Solr needs to change code in lucene, it is done it both, by
two different patches. Both are committed within the same issue. Since each
trunk can depends on the other's trunk, this shouldn't be a problem.

Indeed, it will complicate a bit the build.xmls - like it's done today for
core lucene and backwards. But that's ok I think. I don't expect all Solr
issues to require a change in lucene as well as not all modules issues will.
So that change to the build.xml should not be a frequent operation.

Another thing this will change (and I think for the better) is that a Solr
release might require cutting a Lucene and modules ones, and I think we
should be flexible about that. This also is not something I think will be
frequent ... like today, Solr could still be limited to a certain lucene
release or trunk revision.

I still this is still in line w/ one project, one codebase, just different
levels of the really big parts (Solr, lucene and modules). Committers can be
given access to <root> which will give them access to everything. Others
(modules-committers) can be given access to just that folder (hijacking a
bit from the other thread).

The flexibility of being able to checkout lucene code only is important, at
least to me. I wouldn't want to lose it.

On the IRC stuff - I know that we cannot prevent anyone from discussing on
issues anywhere, and I respect that freedom. It's just that some time ago I
was told that I shouldn't hold 'private' discussions on Lucene, outside the
community. I know that this IRC channel, that's called #lucene, is not
completely outside the community, but here's how it looks to the outsider
(not on IRC):
1) An issue is opened w/ comment "summarizing discussion on IRC ...".
2) Then a couple of hours later (or days), new comment: "more discussion
summary on IRC".
3) Then some comment, some that are not on IRC
4) Then more comment (from an IRC-er): "ok we've discussed this and here's
what we came up with ..."

Feels like we're on a need to know basis here. Remember that when a
discussion is fully open, you might have some comments on what was said in
the process. When you are given the final decision, or a summary, you cannot
comment on what you weren't told. That's a bit frustrating ... though I'm
trying very hard to be involved w/ the mailing list, it feels like I miss
TONS of discussions on IRC ... and what seems worse (as I read somewhere in
the thread) is that you can open an issue w/ an idea (like happened to me),
just to discover the folks on IRC took it all the way to design and impl
proposals, and I was left to read the summarization ...

So by no means am I trying to suggest that IRC discussions should stop. As I
don't, can't and won't ever have control on that. Just like I cannot keep
two people sitting in next rooms to discuss on issues or Lucene outside the
list. But I'd feel better if when a discussion makes it to the list or an
issue, it'd be conducted there from now on, and not as snippets/summaries of
the IRC discussion. Can we keep at least that?

I don't want to get people off their seats w/ that request :). I'm not even
sure I'm in a position to make such requests :). But I'd appreciate if it
can be at least discussed (not on IRC).

Shai

On Tue, Mar 16, 2010 at 5:48 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote:

The primary concern seems to be ensuring that, once we
merge svn, one can still checkout & build & run tests/etc for
Lucene alone.

If we move lucene under Solr's existing svn path, ie:

  /solr/trunk/lucene

and then fixup solr's build files to go and compile sources from the
lucene dir, run tests there, etc., then, one can still checkout & run
lucene fully independently -- this addresses that concern?

So.... how about we start with this approach?  Progress not
perfection...  If somehow this layout is a problem then we can just
move things around, again.

Alot of great progress has already been made on the temporary branch
-- Solr runs fine on Lucene trunk!  And, also on flex.  We need to
settle an initial svn structure so the changes on the branch can
be fully reviewed & then committed to trunk and normal dev can
proceed...

We don't need to solve how modules/contribs, etc., are going to be
fixed, now -- that all can come later.  IRC issues, using GIT instead,
etc. should also be discussed separately.  Let's just pick a place in
svn and free up ongoing dev...

Mike

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

On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless <
lucene@mikemccandless.com> wrote:
>
> If we move lucene under Solr's existing svn path, ie:
>
>  /solr/trunk/lucene
Chiming in just a bit here - isn't there any concern that independent of
whether or not people "can"
build lucene without checking out solr, the mere fact that Lucene will be
effectively a "subdirectory"
of solr... is there no concern that there will then be a perception that
Lucene is a subproject of
Solr, instead of vice-versa?

The way mavenified projects work is that there would instead be a top level
in which both solr
and lucene would be submodules (and thus also subdirectories in svn), with a
dependency
from solr to lucene (in the pom.xml for maven, but easy enough to do with
the build.xml with
ant).  Checking out solr without lucene should be doable (using snapshot
jars from lucene
trunk nightly, maybe?), and the reverse should be easy, as could be checking
out the
top-level and getting everything (including a top-level build.xml which
<include>'s or antcall's
into the subdirectory build.xmls).

It seems really weird to have Lucene appear as a subdirectory of Solr,
especially for people
out there who aren't using Solr.

  -jake

On Tue, Mar 16, 2010 at 5:42 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless
> <lucene@mikemccandless.com> wrote:
>>
>> If we move lucene under Solr's existing svn path, ie:
>>
>>  /solr/trunk/lucene
>
> Chiming in just a bit here - isn't there any concern that independent of
> whether or not people "can"
> build lucene without checking out solr, the mere fact that Lucene will be
> effectively a "subdirectory"
> of solr...  is there no concern that there will then be a perception that Lucene is a subproject of
> Solr, instead of vice-versa?

Who would have this perception?
Casual users will be using downloads.

Likewise, should solr be concerned that it's currently under a lucene
URL?  How many casual users actually understand the difference between
the lucene TLP and the lucene java subproject?

This is really about what makes most sense for development.

-Yonik

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

Where would the modules live?

I'm not sure if I sent it on this thread or somewhere else, but what about
my proposal to have all three sitting under their own directories, w/ their
own trunk/branch/tags, and if it's easier for dev then put all three under
one root (for permission management maybe)?

Shai

On Tue, Mar 16, 2010 at 11:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 16, 2010 at 5:42 PM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
> > On Tue, Mar 16, 2010 at 2:31 PM, Michael McCandless
> > <lucene@mikemccandless.com> wrote:
> >>
> >> If we move lucene under Solr's existing svn path, ie:
> >>
> >>  /solr/trunk/lucene
> >
> > Chiming in just a bit here - isn't there any concern that independent of
> > whether or not people "can"
> > build lucene without checking out solr, the mere fact that Lucene will be
> > effectively a "subdirectory"
> > of solr...  is there no concern that there will then be a perception that
> Lucene is a subproject of
> > Solr, instead of vice-versa?
>
> Who would have this perception?
> Casual users will be using downloads.
>
> Likewise, should solr be concerned that it's currently under a lucene
> URL?  How many casual users actually understand the difference between
> the lucene TLP and the lucene java subproject?
>
> This is really about what makes most sense for development.
>
> -Yonik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>

On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>
>  > Chiming in just a bit here - isn't there any concern that independent of
> > whether or not people "can"
> > build lucene without checking out solr, the mere fact that Lucene will be
> > effectively a "subdirectory"
> > of solr...  is there no concern that there will then be a perception that
> Lucene is a subproject of
> > Solr, instead of vice-versa?
>
> Who would have this perception?
> Casual users will be using downloads.
>

Developers and dev managers at companies doing build vs. buy decisions
regarding
whether they will do one of the following:

1) pay big bucks to get FAST or whatever
2) use Solr (free/cheap!)
3) pay [variable] bucks to build their own with Lucene
4) pay [variable but high] to build their own from scratch

I'm not concerned with casual downloaders.  I'm talking about the companies
and people who
may or may not be interested in making multi-million dollar decisions
regarding using or
not using Lucene or Solr.

  -jake

On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
> I'm not concerned with casual downloaders.  I'm talking about the companies
> and people who
> may or may not be interested in making multi-million dollar decisions
> regarding using or
> not using Lucene or Solr.

Heh - multi-million dollar decisions after a quick glance at an SVN url?

-Yonik

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

I have to agree w/ Jake that putting Lucene under Solr gives the impression
as if suddenly Lucene became dependent on it ... and for really no good
reasons. Are we making that decision to simplify the build of Solr? What are
the problems Solr faces today w.r.t. its build and using a Lucene release or
trunk revision?

I didn't follow the Lucene/Solr merge on general@, because I didn't even
know such a beast exists. So I guess I'm missing something ...

Shai

On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>
>>  > Chiming in just a bit here - isn't there any concern that independent
>> of
>> > whether or not people "can"
>> > build lucene without checking out solr, the mere fact that Lucene will
>> be
>> > effectively a "subdirectory"
>> > of solr...  is there no concern that there will then be a perception
>> that Lucene is a subproject of
>> > Solr, instead of vice-versa?
>>
>> Who would have this perception?
>> Casual users will be using downloads.
>>
>
> Developers and dev managers at companies doing build vs. buy decisions
> regarding
> whether they will do one of the following:
>
> 1) pay big bucks to get FAST or whatever
> 2) use Solr (free/cheap!)
> 3) pay [variable] bucks to build their own with Lucene
> 4) pay [variable but high] to build their own from scratch
>
> I'm not concerned with casual downloaders.  I'm talking about the companies
> and people who
> may or may not be interested in making multi-million dollar decisions
> regarding using or
> not using Lucene or Solr.
>
>   -jake
>

On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <[EMAIL PROTECTED]>
> wrote:
> > I'm not concerned with casual downloaders.  I'm talking
>
> about the companies and people who may or may not be
>
> interested in making multi-million dollar decisions regarding
>
> using or not using Lucene or Solr.
>
> Heh - multi-million dollar decisions after a quick glance at an SVN url?
>

Clearly not.  But just as I think that making the development of
both solr and lucene easier is a noble goal, I think that giving
people the impression that by choosing to "go with Lucene"
*means* they "go with Solr" as their end solution is not what
we want to do.  There are some places where Solr is just not
appropriate but Lucene may be.

Will this impression be "caused" by a SVN directory url
alone? Of course not.  Merging committer lists, locked
releases, *and* a SVN url which shows this?  Yes, I
think the kinds of VPs and CTO's I've talked to and
tried to help decide whether to go with an open-source
search solution could indeed start to get the feeling that
there's really just one apache solution, the
"Solr/Lucene solution".  And if they look into Solr and
decide that this particular application is not for them,
they may then not look deep enough to see whether
doing a custom Lucene application *would be*.

  -jake

Dev is now merged with Solr and Lucene -- that has already passed.  If
that will scare customers away, that's a risk we take -- the benefits
of merged dev outweigh that, in my opinion.

The incremental risk that the details of our svn URLs will scare
people away seems negligible.

And we can always change this up, later, if we decide to.

I think what's important now is a we pick something to un-block trunk
dev.  Sure people can keep working on the branch but I think it'd be
better if we get this simple "svn move" done so that we can get normal
dev going on a shared trunk again.

Mike

On Tue, Mar 16, 2010 at 5:28 PM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>
> On Tue, Mar 16, 2010 at 3:10 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Mar 16, 2010 at 6:01 PM, Jake Mannix <[EMAIL PROTECTED]>
>> wrote:
>> > I'm not concerned with casual downloaders.  I'm talking
>>
>> > about the companies and people who may or may not be
>>
>> > interested in making multi-million dollar decisions regarding
>>
>> > using or not using Lucene or Solr.
>>
>> Heh - multi-million dollar decisions after a quick glance at an SVN url?
>
> Clearly not.  But just as I think that making the development of
> both solr and lucene easier is a noble goal, I think that giving
> people the impression that by choosing to "go with Lucene"
> *means* they "go with Solr" as their end solution is not what
> we want to do.  There are some places where Solr is just not
> appropriate but Lucene may be.
> Will this impression be "caused" by a SVN directory url
> alone? Of course not.  Merging committer lists, locked
> releases, *and* a SVN url which shows this?  Yes, I
> think the kinds of VPs and CTO's I've talked to and
> tried to help decide whether to go with an open-source
> search solution could indeed start to get the feeling that
> there's really just one apache solution, the
> "Solr/Lucene solution".  And if they look into Solr and
> decide that this particular application is not for them,
> they may then not look deep enough to see whether
> doing a custom Lucene application *would be*.
>   -jake

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

But it's actually the reverse?  Solr depends on Lucene but not vice/versa.

(If instead I proposed making Solr a subdir of Lucene then I'd agree....)

So... if you checkout only lucene, you can cd there and do all you do
today with Lucene ("ant test", "ant dist", "svn diff", etc.).

If you checkout solr, you can cd there and "ant test" will run all of
Lucene's and all of Solr's tests.  "svn diff" will include any changes
to lucene and to solr.

Ie this achieves want we want -- Solr to depend on Lucene but not vice
versa, right?

Mike

On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
> I have to agree w/ Jake that putting Lucene under Solr gives the impression
> as if suddenly Lucene became dependent on it ... and for really no good
> reasons. Are we making that decision to simplify the build of Solr? What are
> the problems Solr faces today w.r.t. its build and using a Lucene release or
> trunk revision?
>
> I didn't follow the Lucene/Solr merge on general@, because I didn't even
> know such a beast exists. So I guess I'm missing something ...
>
> Shai
>
> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>>
>>> > Chiming in just a bit here - isn't there any concern that independent
>>> > of
>>> > whether or not people "can"
>>> > build lucene without checking out solr, the mere fact that Lucene will
>>> > be
>>> > effectively a "subdirectory"
>>> > of solr...  is there no concern that there will then be a perception
>>> > that Lucene is a subproject of
>>> > Solr, instead of vice-versa?
>>>
>>> Who would have this perception?
>>> Casual users will be using downloads.
>>
>> Developers and dev managers at companies doing build vs. buy decisions
>> regarding
>> whether they will do one of the following:
>> 1) pay big bucks to get FAST or whatever
>> 2) use Solr (free/cheap!)
>> 3) pay [variable] bucks to build their own with Lucene
>> 4) pay [variable but high] to build their own from scratch
>> I'm not concerned with casual downloaders.  I'm talking about the
>> companies and people who
>> may or may not be interested in making multi-million dollar decisions
>> regarding using or
>> not using Lucene or Solr.
>>   -jake
>

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

+1

I like this proposal!

I agree we should not preclude the future (modules), let's just not
hold up dev today until we solve it.

I agree your side by side solution would allow for us to later factor
up modules (eg analyzers).

Mike

On Tue, Mar 16, 2010 at 5:47 PM, Michael McCandless
<lucene@mikemccandless.com> wrote:
> But it's actually the reverse?  Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests.  "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What are
>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>>>
>>>> > Chiming in just a bit here - isn't there any concern that independent
>>>> > of
>>>> > whether or not people "can"
>>>> > build lucene without checking out solr, the mere fact that Lucene will
>>>> > be
>>>> > effectively a "subdirectory"
>>>> > of solr...  is there no concern that there will then be a perception
>>>> > that Lucene is a subproject of
>>>> > Solr, instead of vice-versa?
>>>>
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders.  I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>>   -jake
>>
>

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

What about tagging and branching?  When we cut a Lucene release we also
tag Solr, even though it's not being released?

  Michael

On 3/16/10 3:47 PM, Michael McCandless wrote:
> But it's actually the reverse?  Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests.  "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera<[EMAIL PROTECTED]>  wrote:
>    
>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What are
>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix<[EMAIL PROTECTED]>  wrote:
>>      
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley<[EMAIL PROTECTED]>  wrote:
>>>        
>>>>          
>>>>> Chiming in just a bit here - isn't there any concern that independent
>>>>> of
>>>>> whether or not people "can"
>>>>> build lucene without checking out solr, the mere fact that Lucene will
>>>>> be
>>>>> effectively a "subdirectory"
>>>>> of solr...  is there no concern that there will then be a perception
>>>>> that Lucene is a subproject of
>>>>> Solr, instead of vice-versa?
>>>>>            
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>>          
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders.  I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>>    -jake
>>>        
>>      
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>    
---------------------------------------------------------------------

Duh -- I meant to reply to Hoss' proposal, below:

On Tue, Mar 16, 2010 at 5:55 PM, Michael McCandless
<lucene@mikemccandless.com> wrote:
> +1
>
> I like this proposal!
>
> I agree we should not preclude the future (modules), let's just not
> hold up dev today until we solve it.
>
> I agree your side by side solution would allow for us to later factor
> up modules (eg analyzers).
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:47 PM, Michael McCandless
> <lucene@mikemccandless.com> wrote:
>> But it's actually the reverse?  Solr depends on Lucene but not vice/versa.
>>
>> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>>
>> So... if you checkout only lucene, you can cd there and do all you do
>> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>>
>> If you checkout solr, you can cd there and "ant test" will run all of
>> Lucene's and all of Solr's tests.  "svn diff" will include any changes
>> to lucene and to solr.
>>
>> Ie this achieves want we want -- Solr to depend on Lucene but not vice
>> versa, right?
>>
>> Mike
>>
>> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>>> I have to agree w/ Jake that putting Lucene under Solr gives the impression
>>> as if suddenly Lucene became dependent on it ... and for really no good
>>> reasons. Are we making that decision to simplify the build of Solr? What are
>>> the problems Solr faces today w.r.t. its build and using a Lucene release or
>>> trunk revision?
>>>
>>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>>> know such a beast exists. So I guess I'm missing something ...
>>>
>>> Shai
>>>
>>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> > Chiming in just a bit here - isn't there any concern that independent
>>>>> > of
>>>>> > whether or not people "can"
>>>>> > build lucene without checking out solr, the mere fact that Lucene will
>>>>> > be
>>>>> > effectively a "subdirectory"
>>>>> > of solr...  is there no concern that there will then be a perception
>>>>> > that Lucene is a subproject of
>>>>> > Solr, instead of vice-versa?
>>>>>
>>>>> Who would have this perception?
>>>>> Casual users will be using downloads.
>>>>
>>>> Developers and dev managers at companies doing build vs. buy decisions
>>>> regarding
>>>> whether they will do one of the following:
>>>> 1) pay big bucks to get FAST or whatever
>>>> 2) use Solr (free/cheap!)
>>>> 3) pay [variable] bucks to build their own with Lucene
>>>> 4) pay [variable but high] to build their own from scratch
>>>> I'm not concerned with casual downloaders.  I'm talking about the
>>>> companies and people who
>>>> may or may not be interested in making multi-million dollar decisions
>>>> regarding using or
>>>> not using Lucene or Solr.
>>>>   -jake
>>>
>>
>

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

I'm just a surprised observer that doesn't seems to get all the trouble
and need for this svn merge.

I have my own private Solr-like framework around Lucene. It uses maven to
build and nicely gets all dependencies to Lucene and Tika whenever I build
or release, no problem there and certainly no need to have it merged into
Lucene's svn!

Professionally i work on a (world-class) geocoder that also nicely depends
on Lucene by using maven, no problems there at all and no need to merge
that code in Lucene's svn!

Wouter

> But it's actually the reverse?  Solr depends on Lucene but not vice/versa.
>
> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>
> So... if you checkout only lucene, you can cd there and do all you do
> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>
> If you checkout solr, you can cd there and "ant test" will run all of
> Lucene's and all of Solr's tests.  "svn diff" will include any changes
> to lucene and to solr.
>
> Ie this achieves want we want -- Solr to depend on Lucene but not vice
> versa, right?
>
> Mike
>
> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>> I have to agree w/ Jake that putting Lucene under Solr gives the
>> impression
>> as if suddenly Lucene became dependent on it ... and for really no good
>> reasons. Are we making that decision to simplify the build of Solr? What
>> are
>> the problems Solr faces today w.r.t. its build and using a Lucene
>> release or
>> trunk revision?
>>
>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>> know such a beast exists. So I guess I'm missing something ...
>>
>> Shai
>>
>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>>>
>>>> > Chiming in just a bit here - isn't there any concern that
>>>> independent
>>>> > of
>>>> > whether or not people "can"
>>>> > build lucene without checking out solr, the mere fact that Lucene
>>>> will
>>>> > be
>>>> > effectively a "subdirectory"
>>>> > of solr... �is there no concern that there will then be a perception
>>>> > that Lucene is a subproject of
>>>> > Solr, instead of vice-versa?
>>>>
>>>> Who would have this perception?
>>>> Casual users will be using downloads.
>>>
>>> Developers and dev managers at companies doing build vs. buy decisions
>>> regarding
>>> whether they will do one of the following:
>>> 1) pay big bucks to get FAST or whatever
>>> 2) use Solr (free/cheap!)
>>> 3) pay [variable] bucks to build their own with Lucene
>>> 4) pay [variable but high] to build their own from scratch
>>> I'm not concerned with casual downloaders. �I'm talking about the
>>> companies and people who
>>> may or may not be interested in making multi-million dollar decisions
>>> regarding using or
>>> not using Lucene or Solr.
>>> ��-jake
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>
>

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

Some of these people got traumatized by maven, now they only can think
in terms of "mash everything together and sprinkle with
hand-downloaded dependency jars".
No offence : )

I, personally, prefer side-by-side layouts. You can add new stuff, and
wire dependencies to the old one, without reorganizing the tree. You
can checkout everything, or just the subset you need.
There is also another way - separate trunks for the modules, so they
can be release-managed separately, but there is a toplevel directory
that svn:external's all these trunks and allows checking
out/building/testing everything at once.

On Wed, Mar 17, 2010 at 11:51, Wouter Heijke <[EMAIL PROTECTED]> wrote:
> I'm just a surprised observer that doesn't seems to get all the trouble
> and need for this svn merge.
>
> I have my own private Solr-like framework around Lucene. It uses maven to
> build and nicely gets all dependencies to Lucene and Tika whenever I build
> or release, no problem there and certainly no need to have it merged into
> Lucene's svn!
>
> Professionally i work on a (world-class) geocoder that also nicely depends
> on Lucene by using maven, no problems there at all and no need to merge
> that code in Lucene's svn!
>
> Wouter
>
>> But it's actually the reverse?  Solr depends on Lucene but not vice/versa.
>>
>> (If instead I proposed making Solr a subdir of Lucene then I'd agree....)
>>
>> So... if you checkout only lucene, you can cd there and do all you do
>> today with Lucene ("ant test", "ant dist", "svn diff", etc.).
>>
>> If you checkout solr, you can cd there and "ant test" will run all of
>> Lucene's and all of Solr's tests.  "svn diff" will include any changes
>> to lucene and to solr.
>>
>> Ie this achieves want we want -- Solr to depend on Lucene but not vice
>> versa, right?
>>
>> Mike
>>
>> On Tue, Mar 16, 2010 at 5:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>>> I have to agree w/ Jake that putting Lucene under Solr gives the
>>> impression
>>> as if suddenly Lucene became dependent on it ... and for really no good
>>> reasons. Are we making that decision to simplify the build of Solr? What
>>> are
>>> the problems Solr faces today w.r.t. its build and using a Lucene
>>> release or
>>> trunk revision?
>>>
>>> I didn't follow the Lucene/Solr merge on general@, because I didn't even
>>> know such a beast exists. So I guess I'm missing something ...
>>>
>>> Shai
>>>
>>> On Wed, Mar 17, 2010 at 12:01 AM, Jake Mannix <[EMAIL PROTECTED]>
>>> wrote:
>>>>
>>>> On Tue, Mar 16, 2010 at 2:53 PM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> > Chiming in just a bit here - isn't there any concern that
>>>>> independent
>>>>> > of
>>>>> > whether or not people "can"
>>>>> > build lucene without checking out solr, the mere fact that Lucene
>>>>> will
>>>>> > be
>>>>> > effectively a "subdirectory"
>>>>> > of solr...  is there no concern that there will then be a perception
>>>>> > that Lucene is a subproject of
>>>>> > Solr, instead of vice-versa?
>>>>>
>>>>> Who would have this perception?
>>>>> Casual users will be using downloads.
>>>>
>>>> Developers and dev managers at companies doing build vs. buy decisions
>>>> regarding
>>>> whether they will do one of the following:
>>>> 1) pay big bucks to get FAST or whatever
>>>> 2) use Solr (free/cheap!)
>>>> 3) pay [variable] bucks to build their own with Lucene
>>>> 4) pay [variable but high] to build their own from scratch
>>>> I'm not concerned with casual downloaders.  I'm talking about the
>>>> companies and people who
>>>> may or may not be interested in making multi-million dollar decisions
>>>> regarding using or
>>>> not using Lucene or Solr</em
Kirill Zakharenko/Кирилл Захаренко ([EMAIL PROTECTED])
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785