Q re merging dev MLs

[Otis Gospodnetic <ot...@yahoo.com>]

Here is my concern:

* Merging the dev lists into a single list.

My concern is that people will be overwhelmed with the volume. Individual -dev lists are already pretty high traffic and hard to follow regularly.  I dread coming back from vacations for this reason.  That stuff is not light reading.  Didn't we see Hadoop do exactly the opposite?  Doug described it as code-base being too big, but I'd say the original list was also too high traffic (was split into common-, hdfs-, and mapreduce- I believe).

Isn't the ML merge going to make it harder for those who wear predominantly Lucene or predominantly Solr hats to track the stuff they care *more* about?  Aren't the things these people care for the most breackages?  If so, wouldn't Hudson tell them about those if we have Solr@Lucene trunk (either directly or via regular Lucene jar imports into Solr svn repo)?

Thoughts?

Thanks,
Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/

Re: Q re merging dev MLs

[Mark Miller <ma...@gmail.com>]

On 03/04/2010 06:00 PM, Otis Gospodnetic wrote:
> Here is my concern:
>
> * Merging the dev lists into a single list.
>
> My concern is that people will be overwhelmed with the volume. Individual -dev lists are already pretty high traffic and hard to follow regularly.  I dread coming back from vacations for this reason.  That stuff is not light reading.  Didn't we see Hadoop do exactly the opposite?  Doug described it as code-base being too big, but I'd say the original list was also too high traffic (was split into common-, hdfs-, and mapreduce- I believe).
>
> Isn't the ML merge going to make it harder for those who wear predominantly Lucene or predominantly Solr hats to track the stuff they care *more* about?  Aren't the things these people care for the most breackages?  If so, wouldn't Hudson tell them about those if we have Solr@Lucene trunk (either directly or via regular Lucene jar imports into Solr svn repo)?
>
> Thoughts?
>
> Thanks,
> Otis
> ----
> Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
> Lucene ecosystem search :: http://search-lucene.com/
>
>    
The Solr dev list is actually reasonably light compared to the lucene 
dev list.

Personally though, I could go either way.

Its certainly easy enough to filter messages with your mail client if 
you still wanted to browse them separately.

I think this could work without merging dev lists, but it would be nice 
to help nurture the cross pollination and merged dev thoughts/planning.

-- 
- Mark

http://www.lucidimagination.com

Re: Q re merging dev MLs

[Chris Hostetter <ho...@fucit.org>]

: versions of HDFS.  So the direction there is the opposite of what's been
: proposed here: introducing layered project dependencies rather than reducing
: them. It's too soon to say how well that split will work, just as I think it's
: difficult to guess how well merging Lucene and Solr will fare.  From
: experience, we know the downsides of Lucene and Solr being split, now we may
: have the opportunity to learn the downsides of being merged!

I don't actually think we really have any clue about the 
benefits/downsides of being "split" .. as a sub-project some people seem 
to expect that Solr is in lock step with Lucene-Java, but if Solr became a 
TLP I think that impression would be reduced.

All of the same goals about wanting to have less duplicated code, and a 
build system that's more closely tied with the Lucene trunk would be just 
as possible if Solr were a TLP -- it's just a matter of modifying Solr's 
processes, refactoring/promoting existing code and encouraging Solr 
developers to contribute "common" code to Lucene-Java as well (and to get 
Solr committers to "reject" contributions that really belong in 
Lucene-Java) -- all of which just requires more effort on everyones part, 
but not neccessarily a change in process or project structure.  The 
increased effort is likely to be the same regardless of wether Solr is a 
subproject, or it's own TLP, or absorbed into Lucene-Java.


-Hoss

Re: Q re merging dev MLs

[Doug Cutting <cu...@apache.org>]

Otis Gospodnetic wrote:
> Didn't we see Hadoop do
> exactly the opposite?  Doug described it as code-base being too big,
> but I'd say the original list was also too high traffic (was split
> into common-, hdfs-, and mapreduce- I believe).

The intent is that eventually HDFS and MapReduce will evolve 
independently.  If a new MapReduce feature depends on a new HDFS 
feature, then MapReduce would have to wait until HDFS releases before it 
can release.  Over time the expectation is that this won't happen much. 
  MapReduce currently develops against a nightly "snapshot" build of 
HDFS and releases will be synchronized for a while yet, but it may 
someday switch to developing against released versions of HDFS.  So the 
direction there is the opposite of what's been proposed here: 
introducing layered project dependencies rather than reducing them. 
It's too soon to say how well that split will work, just as I think it's 
  difficult to guess how well merging Lucene and Solr will fare.  From 
experience, we know the downsides of Lucene and Solr being split, now we 
may have the opportunity to learn the downsides of being merged!

Doug