"Don't come to me with problems, come to me with fixes." has always been a thing. You shouldn't take it too literally or personally. For "fixes" read alternatives or suggestions. e.g. hook in a senior engineer that you know is intimate with the system.
I would argue the difference is that upstream is well known for being defensive about their ideas and pushing back.
On LKML you might get cursed out, but if your fix is solid fix, it has high chances of getting through. Regardless of how true it would be in reality, the atmosphere created by upstream is that I do not expect the same with journald unless you convince redhat management
Indeed. It also means "don't come to me with problems alone." Yes, one can come with a problem, but the exhortation is to come with possible solutions as well and seek guidance on which one is best.
Yes, a lot of awful practices have always been a thing.
> e.g. hook in a senior engineer that you know is intimate with the system.
unless, of course, you don't know said engineer because you don't even work in the same company, you're a just a user seeing a problem in an app you use
> unless, of course, you don't know said engineer because you don't even work in the same company...
Or they work in a different part of the fairly-large company that you both work for.
I guess emmelaich either missed the part of my commentary where I talked about handling inter-organization communication, and/or has never worked at a company where it's simply impossible to know everyone who could reasonably be relevant to the stuff that the company works on.
So put out feelers. Ask everyone if they know anyone....
At least triage it with your best effort.
And it's always been cope. Only the worst kind of person would rather not know about a problem if it's not already solved for them.