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 <gsing...@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<busch...@gmail.com> > 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-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
