[
https://issues.apache.org/jira/browse/SOLR-13888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16967308#comment-16967308
]
Mark Miller commented on SOLR-13888:
------------------------------------
Okay, some of this we can start. I don't plan on redoing all I've lost right
now, heck some of the world has already changed drastically. There are props I
need, things I need to show, time I still need to take, but it's not about my
code changes - I need way more than just code changes.
I am at a crossroads here. It makes me anxious, because these things do. But it
does not worry me. I gave it a very fair try for a very long time. I'm not
afraid of starting on something else - I'm afraid of not doing that for comfort
and laziness. I am built mostly of two opposite styles - mercurial and
solitaire. You may think I'm losing it with one, but I have the other and so
honestly there is always peace somewhere.
I've got things to offer, I'm going to want things in return, it's a no
pressure sale.
A sneak peak is here:
[https://cwiki.apache.org/confluence/display/SOLR/Getting+Started+with+Solr+Development]
I don't like rules beyond the simple stuff Apache gives us. But I need rules if
I'm going to work here. So you are going to have to sign up for those rules.
You are also going to have to help me do this right. Not half assed, not as
quick as we possibly can, but right.
We are going to have SolrCloud test that do nothing but spin up one shard and
index 1 doc. And then 10 shards. And then 100. And then (maybe we move to
nightly, non nightly tests must be 10 seconds or less) 500 or 1000.
And then we are going to do it again and add replicas. And each test is going
to start super stripped down and build up. We are going to run all the
operations we have, concurrently, 100 of times, but fast. 100 times, 1000 times
faster than now. And that is like none of the show, but this is what we will do.
I'm going to show you some stuff, but your not going to get to see all that
I've seen. Not unless we come to some agreement. If we do, I can promise you
that one, I can lead us out of this mess. Two, I can make this thing faster
than you think it can be. And three, it will be fun and enjoyable very soon,
unlike most things now.
And for those that are looking for more. To replace ZooKeeper. To replace Http.
I'm not going to lead you there right now, we'd have to divert paths, but I
promise, this is path to do that as well if we end up choosing to.
And so I'm going to show you some stuff. And it's going to be fast (not
anywhere near as fast as it can and will be) and it's going to be stupid and
incomplete and you are going to have to finish it with me and that is not all,
because getting from here to there will require some lifting even beyond all
that.
And if you want to go anywhere the heck you want after that, great, you will be
able to at least.
> SolrCloud 2
> -----------
>
> Key: SOLR-13888
> URL: https://issues.apache.org/jira/browse/SOLR-13888
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
> Attachments: solrscreen.png
>
>
> As devs discuss dropping the SolrCloud name on the dev list, here is an issue
> titled SolrCloud 2.
> A couple times now I've pulled on the sweater thread that is our broken
> tests. It leads to one place - SolrCloud is sick and devs are adding spotty
> code on top of it at a rate that will lead to the system falling in on
> itself. As it is, it's a very slow, very inefficient, very unreliable, very
> buggy system.
> This is not why I am here. This is the opposite of why I am here.
> So please, let's stop. We can't build on that thing as it is.
>
> I need some time, I lost a lot of work at one point, the scope has expanded
> since I realized how problematic some things really are, but I have an
> alternative path that is not so duct tape and straw. As the building climbs,
> that foundation is going to kill us all.
>
> This i not about an architecture change - the architecture is fine. The
> implementation is broken and getting worse.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
