lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: lucene and solr trunk
Date Tue, 16 Mar 2010 17:55:42 GMT

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> 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).


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

> 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<>
>  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:
> >> For additional commands, e-mail:
> >>
> >>
> >
> > 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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message