On 22.08.24 22:07, Eirik Bakke wrote:
having unmaintained features is the worrying part. Dropping them would be the
ultimate consequence.
I think this is the core disagreement. Dropping a feature is a "one-way
decision"; it permanently throws away work which may have taken people months or
years to create. Leaving a buggy feature in may be annoying, but it's not nearly as
risky. The UI can warn about known limitations.
right, removal of a feature would be the last resort. However, CoS and
profiler are two very different situations.
I said "profiler is another can of worms" because VisualVM appears to
have a fork of the NB profiler. The interesting aspect is that it is
under GPLv2+CPE while the NB bits are under apache v2.
https://github.com/oracle/visualvm/tree/master/visualvm/libs.profiler/lib.profiler/src/org/graalvm/visualvm/lib/jfluid
https://github.com/apache/netbeans/tree/master/profiler/lib.profiler/src/org/netbeans/lib/profiler
VisualVM doesn't appear to be dual licensed. So a NB committer couldn't
even look at the GPL fork without potentially causing trouble
unintentionally. One way to solve this (in theory) as mentioned before,
would be to drop parts of the profiler from NB and consume VisualVM bits
as dependency. But this needs to be discussed separately. None of the
options seem to be great to me + someone would have to be interested
enough to actually do this.
(but lets use a different thread for the profiler topic if possible)
NBI didn't build on JDK 23 anymore, this blocked CI on 23 and the nb-javac 23 PR
Yeah, if a feature breaks the build all by itself, then that's more tricky. My
concern is about proactively removing features, or allowing the development of
new features to break existing features.
the windows copy/paste issue with 193 comments has a similar mode of operation
;)
PR counter is at 0
I think we managed to reduce that one from being a "restart the IDE" problem to
"sometimes you need to press Ctrl+C again" problem [1]. I'd classify that one as a
particularly hard bug to attack for beginners, though, since it required observing the behavior of
the IDE on a Windows machine over many days/weeks.
exactly! Thats why I picked this issue in particular. There is probably
no bug which got more attention than the copy/paste issue (including
reddit thread etc). We (the maintainers), can't really expect that
someone will show up and fix things just by waiting long enough. This
might happen from time to time, but usually this won't happen for the
hard problems as you said. Chances that someone from the community will
fix CoS problems are even slimmer IMO since it is a very specialized
feature going across the whole code base. While the copy/paste impl is
something someone could rewrite during a weekend just to check if it
improves the situation.
best regards,
michael
-- Eirik
[1]
https://github.com/apache/netbeans/commit/910f34f04528f6ba58fb7ac7be985e2486a1f657
and
https://github.com/apache/netbeans/commit/1b01c99f688f5aa8f96932efc825339838906da1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
