[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Francis Herne]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #10 from Francis Herne  ---
>  It's become increasingly clear (also thanks to that remark from Francis) 
> that you consider this project as your own play thing and don't care about 
> how outsiders (as in people still using other products) think about or (can) 
> use it.

I don't think that's an accurate representation at all.

I can't speak for anyone else, but I'm opposed to this feature /because/ it
seems focused on the very small group of KDevelop-developers and wouldn't be of
use to 'outsiders' (for the reasons I described above).

People generally /do/ ignore things that they're entirely uninterested in (to
the extent that it's possible; these things land in email inboxes and on IRC,
and it takes time to determine if they're interesting in the first place).

I'm not, however, uninterested in this suggestion; I believe the original idea
would be actively harmful, and I wanted to explain why before you or anyone
else spent more time trying to implement it. Similarly, when people comment on
review requests they may or may not be interested in the feature itself, but
everyone cares about the state of the codebase and thus can have an interest in
the suggested code changes.

Some personal suggestions on why I think you're having trouble getting things
accepted:

 - Some of your suggestions only address problems found on macOS; or in extreme
cases only when using unusual build options (OSX, Apple-supplied libraries) on
macOS. Thus the issues don't resonate much with other developers, which you
can't really avoid except by explaining them clearly.

 -  The scope and impact of your suggestions can seem very disproportionate to
the benefit, especially when combined with the above. I think everyone working
on the KDevelop codebase finds large parts of it to be overengineered and
overcomplicated, and adding to that for things that only help a tiny proportion
of users is a hard thing to sell.

 - Several of them are workarounds for problems that should be solved in other
ways or upstream - the UI and other interfaces are already confusing to
'outside' users (and me...), so we should focus on making the existing features
solve more problems and be more intuitive, rather than adding extra ones that
interact with them to produce your desired behaviour in your specific use-case.
Again, this is the /opposite/ of focusing on "inside" users.

Sometimes you just seem to shoot yourself in the foot here -- for example, I
really like your diff-context setting, which has a variety of uses and is
intuitive to everyone.
But you presented it as an unintuitive means to workaround Phabricator's buggy
branch-matching - a problem that mainly affects KDE developers, and should of
course be fixed in Phabricator instead - and I get the impression that set off
Milian's "silly workaround" filter.

So, if you want my advice:

 - Think about whether a suggestion makes sense for anything outside your
specific usecase, and whether it's patching over a deficit in another feature
that should be fixed instead. Test whether the problem you're solving is
actually the one you believe it to be.

 - Try to find a solution that adds as little UI (including things like this
proposal, not only buttons) and code complexity as possible. Again, the best
way is likely to fix, improve or extend existing things.

 - Explain clearly about how you thought about the first two things, and which
approaches you've excluded. Which problems does this solve and for whom; why is
this the simplest solution (for users and/or for code). If you feel the need to
write "I believe..." or "It's very probable that..." about the code, you've
probably missed something above.

 - Try to be a little less verbose, and structure your posts clearly. It's not
a writing competition, you can and should use lists instead of full paragraphs.
This may seem like a personal complaint or pointless bikeshedding, but I do
find your posts in particular to have a low information-density and be hard to
read - they're more like a narration of your chain of thought than an
explanation of the resulting points.

Anyway, good luck, and happy hacking...
-Francis

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #9 from RJVB  ---
This was a feature request. Meaning
- you make them for things you think worthwhile but maybe not urgent, or not
enough to dive in immediately yourself or out of your grasp.
- you provide arguments in favour, and defend those reasonably against ditto
counter-arguments (I'm not convinced that applies to calling "power-user
feature" for a tool that's targeted largely at power-users...). I wasn't
planning on making this an endless ping-pong game.

> you are merely talking about how somebody else could write toy stuff you 
> think could be useful. That is just not worth anyone's time.

That just confirms my diagnose above.

Damn, is anyone here being paid to work on KDevelop? If not, there's no such
thing as wasting anyone's time. We're all participating because we want to,
feel like it, like to, etc. and the only time you can waste is your own if you
adhere to a simple rule. Ignore remarks, suggestions, discussion etc. you don't
see the point of, for risk of indeed wasting everyone's time there. For the
record: that's what I do (and am going to try to do here too).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Sven Brauch]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #8 from Sven Brauch  ---
The whole situation makes me a bit sad because I know you want to actually help
and it is important to you, otherwise you'd not have been around as long. It
also makes me sad because I know you are well capable of actually fixing
important things (e.g. disabling the JIT for old Qt versions in kate was a very
useful recent contribution of yours). My point is this misunderstanding:

> Nor did I write the devil's advocate reaction to Francis' remark
> about one of your commits, above.

Feel free to do so. The feature Francis removed was idiotic, and it was a
mistake of mine to add it in the first place. You will however notice that
there is no five-page mailing list thread or bug report about how useful it
would be before introducing it. I added it, it was useless, Francis deleted it
again, done. Total discussion 2 lines, total time spent discussing 30 seconds.

The point here is not that "core developers can get their toy stuff in but
others can't". The point here is that you didn't submit toy stuff, you are
merely talking about how somebody else could write toy stuff you think could be
useful. That is just not worth anyone's time.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #7 from RJVB  ---
You can be proud of me, I spent a couple of hours composing answers I didn't
write... Nor did I write the devil's advocate reaction to Francis' remark about
one of your commits, above.

I will write this though.

It's become increasingly clear (also thanks to that remark from Francis) that
you consider this project as your own play thing and don't care about how
outsiders (as in people still using other products) think about or (can) use
it. Accuracy and whether or not others share this opinion are things *I* don't
care about at this point.

You're also not alone in this, it's a sad side-effect in any kind of
development when a majority of people who become involved do so because it's
part of their training.

I know I'm mostly an auto-didact who lacks almost all formal training, so many
things inside KDevelop are done in ways I never had (reason) to deal with and
are thus just beyond my grasp. What I do have though is a bit of experience
accumulated since the early 80s working with anything from TRS80s and C64s to
VAX minis, (ageing) high-end workstations and special-purpose hardware like
custom-made microcontrollers working as a student, scientist and research
engineer in domains like Artificial Life, robotics,
neuro-/bio-medical/psychology research, driving simulation and driver
behaviour.

I think that gives me a pretty damn good idea of what can be useful, what
doesn't work so well and what compromises one might need to make, in a broader
scope than my own petty projects. You can of course discard that idea, in which
case I'm going to stop wasting *my* time (and sanity) and stop contributing
anything but reports about obvious bugs.

I'd love to help fix problems I see the importance of, provided that's a 2-way
process and I'm not just lending idle brain cycles in some SETI@Home way. I
want to be able to stand behind my contributions, esp. when made for other
reasons than being a commissioned (and accepted!), paying job.

(Reply kept within less than 1 page on my end.)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Sven Brauch]

https://bugs.kde.org/show_bug.cgi?id=387259

Sven Brauch  changed:

   What|Removed |Added

 CC||m...@svenbrauch.de

--- Comment #6 from Sven Brauch  ---
Sigh, Rene, we have so many real problems in KDevelop. Could you maybe look at
one of them instead of writing pages of text about virtual issues nobody has
ever had and nobody will ever have? It's such a waste of time, for you and for
everyone reading this ...

In general, if you feel like you want to write a mail or bug starting with "it
would be useful" just don't ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #5 from RJVB  ---
> The correct way to fix options that are missing from the UI is of course to 
> add them to the UI; or ideally to make them unnecessary by doing the right 
> thing without configuration.

True, but the UI is already complex, which means there's always someone who'll
object to adding yet another widget for something they feel isn't of sufficient
general use.
Wasn't it FireFox that had a not-really-hidden lowlevel interface to *all* its
internal options, including those that would probably never merit a UI? That's
a bit what I have in mind here, in a simpler and more flexible way.

Undocumented environment variables, yeah, those are a PITA. Many of them merit
documentation, and I'd hope that anyone introducing a feature with a broader
audience would take the time to provide that documentation.

Would a feature request to make the default env. profile session-specific have
more chance?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Francis Herne]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #4 from Francis Herne  ---
The correct way to fix options that are missing from the UI is of course to add
them to the UI; or ideally to make them unnecessary by doing the right thing
without configuration.

Users aren't going to lookup undocumented environment variables and then set
them via KDevelop profiles. The only audience for this is developers of
KDevelop, and there aren't enough of use to be a sane target audience (c.f.
https://cgit.kde.org/kdev-python.git/commit/?id=6831ff , I couldn't find *one
single case anywhere* of someone other than Sven having used it).

Ditto for the logging output of KDevelop itself; no-one cares unless they're
debugging it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[RJVB]

https://bugs.kde.org/show_bug.cgi?id=387259

--- Comment #3 from RJVB  ---
You can already set dedicated profiles for such actions, so it's already
possible to apply a different profile to KDevelop itself.

Applying the default env. profile to KDevelop is trivial to do, the only thing
missing is support for session-specific env. profiles -- something which is
probably useful even without it being applied to KDevelop itself.

Of course you can set up session-specific wrappers around KDevelop. It's just
not elegant; reducing the number of job-specific scripts etc. you have to write
is IMHO among the things modern development tools are designed to do. I don't
see how this is more power-user than providing a built-in HTML documentation
browser (which you can easily launch manually too).

Not to mention the fact that KDevelop is also used on platforms where scripts
aren't such an intuitive tool for everyone.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Francis Herne]

https://bugs.kde.org/show_bug.cgi?id=387259

Francis Herne  changed:

   What|Removed |Added

 CC||m...@flherne.uk

--- Comment #2 from Francis Herne  ---
This would be a bad idea.

When I want to debug things from KDevelop I have environment profiles to
override XDG paths, preload non-standard libs, etc. This would of course fail
terribly if applied to KDevelop itself.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 387259] Make environment profiles session specific and apply them as early as possible

[Milian Wolff]

https://bugs.kde.org/show_bug.cgi?id=387259

Milian Wolff  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Milian Wolff  ---
power-user feature that is easily solved by running the kdevelop session from a
batch script that sets the env vars.

-- 
You are receiving this mail because:
You are watching all bug changes.