In D3909#109802, @karol-bisztyga wrote:

I also noticed there is a lib inside the Docker container that is different from our services/lib.

I don't understand what is the problem here? Do you mean /lib? This folder is probably in every Unix. All contents of services/lib are being copied to transferred. So the folder structure is flattened. Something like this happens:

cp -r services/lib/* /transferred
cp -r services/backup/* /transferred # or blob, depends on the service

I couldn't name this src as it would get overwritten by specific service's src.

I think I recall this lib folder having third-party dependencies. I guess it just feels confusing to have such a generic name, especially given it means something different inside of Docker versus in our repo.

I think it's more simple to use the same directory structure we have in the repo. That way we don't have to reason about two distinct directory structures.

Ok but at the same time in D3904 you said

I don't think it's crazy for the folder to have a different name inside vs. outside the container, and the extra line in the Dockerfile isn't a big deal in my opinion.

So I think we should be consistent here. Either we take a laid back approach and allow ourselves to modify the structure or we keep it tight. I see some opposite ideas here, do I miss something?

Yeah you're absolutely right, this was inconsistent of me. After thinking about it more – I think it would be ideal if we could preserve the same structure between the repo and what's inside Docker. This will have the additional benefit of making things more consistent when we want to build outside of Docker, which I think is a goal based on recent research from @geekbrother.

What do you think of trying to preserve the same structure, and to use either .dockerignore or selective COPY instructions in the Dockerfile to copy over just what we need?

What do you think of changing the code so that instead of lib_src we have lib/src

Do you mean /lib/src/ or /transferred/lib/src? I bet the latter. What's wrong with lib_src anyway? I don't get it to be honest. It indicates that the code comes from the mutual space. And I don't see it as problematic at all.

I don't think lib_src is a good name. From the name I don't know what's going on it with, what it means, why it exists. To be honest, lib/src isn't much better though...

Right now on master we have a folder services/lib that inside it only has a single folder lib_src. This is the sort of deeply nested, poorly named structure that I've been pushing us for months to avoid. I think the directory structure has recently been improved but I wish that I didn't have to push for it – that you could own the process of coming up with a consistent, minimally nested, clearly named directory structure that could be mirrored between Docker and outside of it.

instead of lib/double-conversion we have 3rd-party/double-conversion (or something similar)?

Do we have something like lib/double-conversion? I don't see anything like it, can you specify what you mean, please?

I don't have time to dig up why I thought this was the case right now. git grep "lib/double-conversion" gives many results, so I suspect that should help clarify what I'm referring to.

It's really frustrating that I have to keep writing these long essays... @karol-bisztyga the amount of time I spend writing essays on your diffs, generally repeating the same thing day-in-day-out, is deeply frustrating for me.

As long as you don't come up with an alternative I cannot read your mind and see what is your idea of an ideal directory structure. For me this structure's good. For you, not.

I am not always going to be able to give you better suggestions. This is something you'll need to get used to... your reviewer won't always know what the right solution is.

Right now, we have a huge issue where reviewing your diffs is very expensive. We need to move more of that work away from the reviewers, and to the diff author.

I should be able to tell you things like "this looks fishy" or "I don't like this, what are some alternatives?" without having to spend hours myself coming up with solutions.

Now, I can keep coming up with different names and you can keep hating every single one of them just saying that it's bad, nothing else. Where are we going to go with this?

I strongly disagree. You absolutely can come up with better names. All you need to do is to listen to the feedback, grok it, and try to respond to it.

I have spent a lot of time trying to explain this feedback to you. Are you still confused about the feedback? I am telling you (repeatedly, over the course of many diffs) the same thing:

1. The structure should not be deeply nested
2. The names of things should clearly explain what they are
3. We should have the same structure within the Docker container as outside

I am not going to be able to give you the answer here. It's your job to take this feedback, consider it, grok it, and then to come back with a proposal that fits the feedback.

As a side note - should we ever give negative feedback without an alternative? What values does it bring?

We absolutely, definitely, 100% should do this. We need to do more of this. I have been pushing @palys-swm to do more of it. This idea you have that feedback should only be given when alternatives are presented is very unhealthy.

The value should be clear. If something is fishy / bad about the proposed code, the value is to improve it. The diff author should be able to take the feedback and independently come up with alternatives.

A senior engineer doesn't need solutions spelled out to them. They can be given a high-level problem, and they can come up with proposed solutions for the problem. That is what we are looking for here from you.

I don't understand why would you accept this? What is the purpose of accepting here if you think the directory structure is broken so much? What am I supposed to do with this? Land this, create a follow-up task, and hear again that I shouldn't do this again? I'm going to request changes I think.

Up to you. I made it clear why I accepted this when I accepted it, so I'm not sure what you're confused about. The directory structure has already been polluted, so I don't think this diff is making things worse.

See, I want to cooperate in the most efficient way possible, but for now, I have a feeling that anything I do will be wrong and you're going to have a problem with whatever path I take. The problem is, you don't specify what exactly you expect, and then I do something and it is usually not what you'd like, and then I get an essay from you on what I could do better, etc.

In these situations, you should ALWAYS schedule a meeting. I've given you this feedback before – if you're about to update a diff and you think it will lead to more wasted time (like I am currently wasting time), then PLEASE save us BOTH the time and schedule a meeting.

Back to the topic, I assume you wanted some follow-up without editing this directory name here. I don't understand why is that. You didn't have a problem with renaming scripts in D3906, so why don't we change the folder name here (as this is the first diff in this stack right now that modifies anything in this directory so it seems to be a good place)?

What I want is for you to come up with a directory structure that addresses the feedback I have repeatedly communicated to you. I am not sure what you are suggesting now (what folder name?).

I don't think a meeting is necessary - all doubts have been answered.

You are right, this is an oversight

I got information that Tomek is sick and I got a green light from Ashoat to land this. Therefore I'm removing Tomek from the review and landing this. @palys-swm if you ever want to return to this, feel free to do it.