lucene and solr trunk

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

lucene and solr trunk

Yonik Seeley-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Mark Miller-3
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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Robert Muir
On Mon, Mar 15, 2010 at 11:41 PM, Mark Miller <[hidden email]> 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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

hossman
In reply to this post by Yonik Seeley-2
: 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: lucene and solr trunk

Uwe Schindler
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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Simon Willnauer
On Tue, Mar 16, 2010 at 8:18 AM, Uwe Schindler <[hidden email]> 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
>> 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).

+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

>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael Busch
In reply to this post by Uwe Schindler
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.
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>    


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael Busch
In reply to this post by Simon Willnauer
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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: lucene and solr trunk

Uwe Schindler
In reply to this post by Uwe Schindler
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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
In reply to this post by Michael Busch
On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <[hidden email]> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Mark Miller-3
In reply to this post by Simon Willnauer
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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Michael McCandless-2
In reply to this post by Yonik Seeley-2
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Shalin Shekhar Mangar
In reply to this post by Mark Miller-3
On Tue, Mar 16, 2010 at 3:44 PM, Mark Miller <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Mark Miller-3
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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Robert Muir
In reply to this post by Simon Willnauer
On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
<[hidden email]> 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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Grant Ingersoll-2
In reply to this post by Michael Busch

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
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Erick Erickson
In reply to this post by Robert Muir
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 <[hidden email]> wrote:
On Tue, Mar 16, 2010 at 3:43 AM, Simon Willnauer
<[hidden email]> 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
[hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Andrzej Białecki-2
In reply to this post by Mark Miller-3
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


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Mark Miller-3
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




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: lucene and solr trunk

Yonik Seeley
In reply to this post by Michael Busch
On Tue, Mar 16, 2010 at 2:51 AM, Michael Busch <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

123