> 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. > 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. -- Eirik [1] https://github.com/apache/netbeans/commit/910f34f04528f6ba58fb7ac7be985e2486a1f657 and https://github.com/apache/netbeans/commit/1b01c99f688f5aa8f96932efc825339838906da1 From: Michael Bien <mbie...@gmail.com> Date: Thursday, August 22, 2024 at 1:20 PM To: "dev@netbeans.apache.org" <dev@netbeans.apache.org>, Eirik Bakke <eba...@ultorg.com> Subject: Re: [DISCUSS] Projects, Builds and IDE magic On 22.08.24 18:04, Eirik Bakke wrote: (I could open another can of worms which is the NB profiler https://github.com/apache/netbeans/issues/7323) Indeed; I use the NetBeans profiler quite a lot. I see a worrying line of argument in these discussions: Some contributors say, quoting from the PR above, "I don't use [feature X] at all personally", another one says "me neither", and then "either we need someone to work on it ... or we drop it". I disagree with this: Dropping a feature is permanent, whereas leaving it in avoids disrupting existing users, and allows occasional fixes to be accepted over time. having unmaintained features is the worrying part. Dropping them would be the ultimate consequence. and sometimes there is not much warning, here an example: - NBI didn't build on JDK 23 anymore, this blocked CI on 23 and the nb-javac 23 PR - NBI is de facto deprecated and not updated anymore, tests didn't run either - so we ended up simply removing a big chunk of it (downloader package) "but I like the downloader" wouldn't have helped there unfortunately unless it meant "let me quickly rewrite the downloader". The NB profiler is probably still far away from being dropped. It might also be possible to use some bits from VisualVM, but someone would have to actually do that. For a huge piece of software such as NetBeans, different users are going to use different features, and bugs are a fact of life. Doing big workflow changes such as "switch from maven to gradle" will not eliminate bugs, but rather replace them with another set of bugs. Over time, each user picks a workflow, and learns about the relevant bugs and how to work around them. If a particular bug is particularly egregious, the user might find it worthwhile to develop a patch, and perhaps submit a PR. the windows copy/paste issue with 193 comments has a similar mode of operation ;) PR counter is at 0 (In the profiler's case, as an example, Peter Hull and Lars Bruun-Hansen contributed a big patch in 2021; see https://github.com/apache/netbeans/pull/2700 .) In the case of https://github.com/apache/netbeans/issues/7323 and similar issues, ideally we would figure out how to encourage the original issue submitter to develop a fix... after all, all NetBeans users are also software developers themselves! the NetBeans project 65 on the PMC or so. So there would be a feature to adopt for everyone ;) -mbien -- Eirik
