I am not personally attacking anyone.

Everyone here does good work in one way or another.

However, if you cross a bar of prolific vs attention to detail, tests, doc,
and things beyond just you, I do hold you to a higher standard.

You are super prolific and your care for others following your footsteps or
full consideration to things, is lacking. I see nothing personal about it,
it’s a pure code and work observation.

You have good ideas, you can spin code, that’s awesome, but your often
using that power in a way that clears a lot of ground without a lot of
replacement tree planting.

I’ve said this 50 times, I’ve said this to the PMC more than once, it’s
nothing personal. Personally you are a great human and enjoyable to
interact with. I always enjoy you, my wife still tells me she enjoys you.

I’ve got problems with others work as well, but no one else seems to have
the same disregard for the other devs while working.

I wish Yonik would document more for mere mortals. I wish AB would look at
more the costs he adds to startup and shutdown. I wish, I wish... I dint
care as long as you have a cooperative attitude.

And I can help with the area people are lacking.  It’s no free lunch, it’s
a going to be a pain I. The ass, we can talk another that when I have my
proposal planned.

There is tons of stuff you can help with project with, prolific people are
valuable. But we need to figure out a better way to operate and we need to
start from more stable ground.

I’m not tossing some design on you. We have a design. It’s fine. Our impl
and foundation are bad, they have always been bad, we are going backward
faster than forward.

Most of the worst and basic code is mine.

We all write bad code. If you are open to owning that your efforts could be
improved in various area - maybe even just to please the others we work
with, that’s enough for me. It’s fine then. But an obstinate disregard for
the fact that we all share this project ... I can’t work wile with it.

Anyway, I’ve got stuff for us to build with. I’d rather you spend your time
making things fast that we care about and not ghosts of the past.

I know everyone has wanted that. I’m not here saying you guys fucked up.
I’m at the head of that list. It’s our project.

Mark

On Sat, Nov 2, 2019 at 6:32 PM Noble Paul <noble.p...@gmail.com> wrote:

> Hi,
>
> I believe there is a consensus on what is wrong with the way we have built
> the cluster state and overseer. We need to focus a bit more on the design
> aspect. Design, according to me, has the following elements:
>
> * How does it work?
>
> * What are the performance characteristics? Can it be done more
> efficiently?
>
> * What are the public touch points?
>
> ** Which are the files we store in ZK? Are they expected to be watched
> always?
>
> ** Or are they read on demand?
>
> ** The public APIs. Does it make sense to the user? Can it be further
> simplified? How does it compare to the other APIs in the system?
>
>
> We, as a community, do a bad job in dealing with these. While we focus on
> internal things, these are not discussed before it is too late. We usually
> do coding, tests, code review (sometimes) and commit. This leads to huge
> technical debt.
>
>
> This is not to put blame on one person or a group of people. (I
> occasionally see people discussing design issues upfront, I just hope that
> is the norm.)
>
>
> Now, why am I discussing this in this thread?
>
>
> While we agree there are problems, we are trying to solve the problem
> using the same process we used to create these problems. Again, I'm not
> questioning the intent or competence of anyone. Unless we set the process
> right, we are doomed to make the same mistakes again.
>
>
> I whole heartedly endorse any effort to improve SolrCloud/overseer. At the
> same time I fail to see us leveraging the collective experience of our
> community through meaningful discussion.
>
>
> I hope we don't resort to personal attacks and use this as an opportunity
> to improve our processes.
> Thanks
>
> On Sun, Nov 3, 2019, 9:52 AM Scott Blum <dragonsi...@gmail.com> wrote:
>
>> Very much agreed.  I've been trying to figure out for a long time what is
>> the point in having a replica DOWN state that has to be toggled (DOWN and
>> then UP!) every time a node restarts.  Considering that we could just
>> combine ACTIVE and `live_nodes` to understand whether a replica is
>> available.  It's not even foolproof since kill -9 on a solr node won't mark
>> all the replicas DOWN-- that doesn't happen until the node comes back up
>> (perversely).
>>
>> What would it take to get to a state where restarting a node would
>> require a minimal amount of ZK work in most cases?
>>
>> On Sat, Nov 2, 2019 at 5:44 PM Mark Miller <markrmil...@gmail.com> wrote:
>>
>>> Give me a short bit to follow up and I will lay out my case and proposal.
>>>
>>> Everyone is then free to decide that we need to do something drastic or
>>> that I'm wrong and we should just continue down the same road. If that's
>>> the case, a lot of your work will get a lot easier and less impeded by me
>>> and we will still all be happier. Win win.
>>>
>>> If we can just not make drastic changes for a just a brief week or so
>>> window, I'll say what I have to say, you guys can judge and do whatever
>>> you'd please.
>>>
>>> - mark
>>>
>>> On Fri, Nov 1, 2019 at 7:46 PM Mark Miller <markrmil...@gmail.com>
>>> wrote:
>>>
>>>> Hey All Solr Dev's,
>>>>
>>>> SolrCloud is sick right now. The way low level Zookeeper is handeled,
>>>> the Overseer, is mix and mess of proper exception handling and super slow
>>>> startup and shutdown, adding new things all the time with no concern for
>>>> performance or proper ordering (which is harder to tell than you think).
>>>>
>>>> Our class dependency graph doesn't even work - we just force it. Sort
>>>> of. If the whole system  doesn't block and choke it's way to a start slow
>>>> enough, lots of things fail.
>>>>
>>>> This thing coughs up, you toss stuff into the storm, a good chunk of
>>>> time, what you want eventually come back without causing too much damage.
>>>>
>>>> There are so many things are are off or just plain wrong and the list
>>>> is growing and growing. No one is following this or if you are, please back
>>>> me up. This thing will collapse under it's own wait.
>>>>
>>>> So if you want to add yet another state format cluster state or some
>>>> other optimization on this junk heap, you can expect me to push back.
>>>>
>>>> We should all be embarrassed by the state of things.
>>>>
>>>> I've got some ideas for addressing them that I'll share soon, but god,
>>>> don't keep optimizing a turd in non backcompat Overseer loving ways. That
>>>> Overseer is an atrocity.
>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://about.me/markrmiller
>>>>
>>>
>>>
>>> --
>>> - Mark
>>>
>>> http://about.me/markrmiller
>>>
>> --
- Mark

http://about.me/markrmiller

Reply via email to