> 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. > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: java-dev-help@lucene.apache.org > > --0016e6d77ed3d566110481eeb4a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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

How about this structure:

<root>/solr/t= runk

<root>/lucene/trunk

<root>/modules/tru= nk

<root> can be left out if we don't th= ink 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 rele= ase 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 supp= orts 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. Bo= th 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 thin= k. 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 bet= ter) 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 c= ertain lucene release or trunk revision.

I still this is still in line w/ one project, one codeb= ase, just different levels of the really big parts (Solr, lucene and module= s). Committers can be given access to <root> which will give them acc= ess 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 o= nly is important, at least to me. I wouldn't want to lose it.

On the IRC stuff - I know that we cannot prevent anyone fro= m 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' d= iscussions on Lucene, outside the community. I know that this IRC channel, = that's called #lucene, is not completely outside the community, but her= e'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 th= is and here's what we came up with ..."

F= eels like we're on a need to know basis here. Remember that when a disc= ussion 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 co= mment 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 some= where in the thread) is that you can open an issue w/ an idea (like happene= d to me), just to discover the folks on IRC took it all the way to design a= nd impl proposals, and I was left to read the summarization ...

So by no means am I trying to suggest that IRC discussi= ons 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 discus= s on issues or Lucene outside the list. But I'd feel better if when a d= iscussion makes it to the list or an issue, it'd be conducted there fro= m 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 reques= ts :). But I'd appreciate if it can be at least discussed (not on IRC).=

Shai

On Tue, M= ar 16, 2010 at 5:48 PM, Grant Ingersoll <gsingers@apache.org> 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<buschmic@gmail.com> =A0wrote= :
>>
>>> Also, we're in review-and-commit process, not commit-and-r= eview. =A0Changes have to be
>>> proposed, discussed and ideally attached to jira as patches fi= rst.
>>>
>> 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 n= ot
>> 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 h= ave 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. =A0Furthermore, it is incumbent on the people working on the bran= ch to then present and discuss when/how to merge to trunk, just like any bi= g patch.

------------------------------------------------------= ---------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

--0016e6d77ed3d566110481eeb4a6--