Re: some background on bugfixing in NetBeans

A lot of the time, it's a question of resources. There are many things 
we'd like to do, and I'm sure there are many things that appear to be 
"no brainers" and very easy to accomplish, etc, "just a few minutes of 
work is all it would take", etc, but there are hundreds, perhaps 
thousands, of items like that.

That's why I think the First Patch program is so great. Now you can 
scratch your own itch. Writing an article about that program at the moment.

Gj


On 09/29/2011 04:01 PM, Rob Ratcliff wrote:
> John and Jirka,
>
> I'd like the core NB developer team to consider these points I've read 
> elsewhere (such as in the Eclipse forums):
>
> 1) The user is always right.
> 2) You are NOT the user.
>
> First of all, I've been using NB for 11 years or so. I'm one of the 
> biggest advocates of NB here in Austin, TX. I've also been developing 
> production Swing, JEE, Database applications for over 12 years and 
> developing in Java for 15 years.
>
> Since I'm a contractor, for me to take the time to submit a bug or 
> enhancement request means that it is something truly irritating since 
> the time spent to write the bug and battle with the developers over 
> the bug is non-billable. I typically don't have time to get up the 
> learning curve on the source code of every single module that I submit 
> a bug for so developing a patch or a work-around solution isn't likely 
> to happen plus its hugely inefficient compared to the Oracle-paid 
> developers that are supporting that module.
>
> I have spent many hours in nearly endless discussions via Bugzilla on 
> why a certain feature should be implemented or a bug fixed; many of 
> these discussions were related to chronic problems, usability or 
> strategic direction, which should be considered by a wider audience.
>
> For instance, you mentioned the menu selections requests, I submitted 
> a bug where I simply wanted the most common tasks that a Java 
> developer executes typically while writing a class available via right 
> click: compile, run, <vcs> update, <vcs> commit, <vcs> show 
> annotations, etc. These are available in other menus, but you have 
> move out of the editor to go find them or find the file in the node 
> tree. The response I got was that they clutter up the menus and so it 
> was closed as WONTFIX. Oddly enough, Eclipse has these menu items 
> (except for compile for some reason).  Application usability issues 
> need to be considered by a wider audience than a sole developer. The 
> voting system doesn't seem to have much traction and doesn't seem to 
> get used much either.  There needs to be a usability evaluation 
> team/committee that looks at the workflow and request and determines 
> the best solution or philosophy.
>
> In another bug, I asked that "run" file be available for any project 
> (NB modules, JEE, etc.) since many times it is convenient to add a 
> main method to a class to do a quick test. The response I got is that 
> I should use JUnit testing, which is always a good thing, but it 
> dictates a workflow that may not be convenient to the user, especially 
> if the class already has a decent main method already present.
>
> I asked in another bug that the NB "platform/module" build system 
> behave with the same finesse as the NB "projects" build system. The 
> response I got was to switch to Maven and write my own build scripts 
> since Ant is being abandoned. This is a strategic problem. The NB 
> module build system is almost there and the NB team or developer has 
> decided to stop all work on it and force all of the users to write 
> their own build system until an entirely new, incompatible build 
> system is developed. This is a huge disregard for users time and "puts 
> off" developers from even using the NB platform. There needs to be 
> more over-site of these types decisions. You all want people to 
> develop rich applications using the NB platform and yet aren't 
> ensuring that the development tools are mature and complete from 
> end-to-end -- from project creation to deployment.
>
> There have been many bug reports related to the chronic issues such as 
> the "scanning" problem that has plagued NB for many years. I had 
> suggested that until an efficient way to do this automatically is 
> developed that a "refresh project" button similar to Eclipse be added 
> to allow the user to manually refresh the project when changes 
> happened outside of NB. This scanning problem has discouraged many 
> developers that I demoed NB to from even pursuing the use of NB, but 
> yet it took many years for this to be addressed with lots of pushing 
> by the users. It appears that NB 7 may have mostly solved it finally.  
> (Prior to this, somebody else created a "scan external" plug-in to 
> allow manual scans which partially solved the problem. It would have 
> been much  easier for the core developer to have added it though.) Why 
> didn't the NB management apply all available resources to fix this 
> chronic problem quickly rather than letting it linger for years? It 
> gave NB two black eyes and pushed many away from NB over the years. (I 
> nearly even left NB because of it!)
>
> Anyway, there needs to be a better process than endless arguing with 
> developers over whether an enhancement or bug should be addressed. 
> Perhaps a usability team, a NB strategic direction team, etc, I don't 
> know.
>
> Also, I believe that there needs to be more consideration of the 
> reported million users' time. Telling thousands of impacted users 
> about a work-around without actively addressing the problem just 
> wastes thousands of hours of people's time when it may have taken 
> hours for one of the core developers to fix.
>
> Thanks for your time and consideration,
>
> Rob
>
>
> On 09/29/2011 07:05 AM, John Yeary wrote:
>> Hello All,
>>
>> I think that Jirka is right. WONTFIX is a valid option. There are 
>> situations that warrant it. There are situations where it would be 
>> impossible to implement, or that compared with alternatives, you take 
>> a different path.
>>
>> Also no matter how much someone wants a "matter transporter", 
>> NetBeans is not going to have it. Yes, I know it is a little absurd, 
>> but it makes the point.
>>
>> Obviously, no one wants to hurt someone's feelings, but I think it is 
>> going to happen. It is a fact of life.
>>
>>  I would suggest that a close with a WONTFIX should have a narrative 
>> about why it won't be fixed. It does not have to be long.
>>
>> For example, "the module in question is no longer supported, and this 
>> issue is being closed as WONTIFIX". Short and to the point.
>>
>> John
>>
>> 2011/9/29 Jiří Kovalský <[email protected] 
>> <mailto:[email protected]>>
>>
>>     Robert,
>>
>>       while I understand how frustrating closing a bug as WONTFIX
>>     could be for its reporter, it is a valid option. There will
>>     always be a kind of design issues without any clearly best
>>     solution. It happens that there is a group of users supporting
>>     solution/fix A whereas solution B which is sometimes a true
>>     opposite of A has equal number of supporters. If we have already
>>     been through such discussion in the past and solution A was
>>     implemented, changing it to B would surely please its fans but
>>     next day a new bug would be opened as regression from the
>>     previous state.
>>
>>       I don't understand how creation of such a committee would help
>>     in this case for example. In addition to that quick and clear
>>     resolution of bug could be perceived as less insulting to some
>>     people than leaving the issue open for years until it gets invalid.
>>
>>     My two cents,
>>     -Jirka
>>
>>     Dne 28.9.2011 00:55, Robert Ratcliff napsal(a):
>>
>>         To save both the developer and the submitter time, it would
>>         be nice to
>>         just have a bug fix category “Review Required” and the owner
>>         assigned to
>>         the “Bug Review Board” (in this case the NetBeans Governance
>>         Board)
>>         rather than the two haggling over what should be done. The
>>         feature or
>>         bug request may required more review than from a single
>>         developer.
>>
>>         Closing the bug as ‘WONTFIX” is highly insulting, especially
>>         when one
>>         has spent a lot of time writing up the enhancement request
>>         and it comes
>>         down the developer’s personal opinion on what is “good”
>>         rather than what
>>         is “good” for the user-base at large.
>>
>>         *From:*John Ceccarelli
>>         [mailto:[email protected]
>>         <mailto:[email protected]>]
>>         *Sent:* Tuesday, September 27, 2011 4:24 PM
>>         *To:* [email protected] <mailto:[email protected]>
>>         *Cc:* John Yeary
>>         *Subject:* [nbdiscuss] Re: some background on bugfixing in
>>         NetBeans
>>
>>
>>         The intent was to send this to nbdiscuss, as that is the
>>         correct forum
>>         for these types of discussions. I may put it up on the wiki
>>         as well.
>>
>>         -J
>>
>>         On 9/26/2011 3:21 PM, John Yeary wrote:
>>
>>         Is the intent to send out this message to all the forums, post on
>>         NetBeans site, both?
>>
>>         Sent from my iPhone
>>
>>
>>         On Sep 23, 2011, at 17:54, John Ceccarelli
>>         <[email protected]
>>         <mailto:[email protected]>
>>         <mailto:[email protected]
>>         <mailto:[email protected]>>> wrote:
>>
>>            Hi folks,
>>
>>            I know there has been some discussion about bugs and some
>>         people
>>            expressed frustration that bugs were not being evaluated
>>         quickly
>>            enough by the NB team. I put together this email just so
>>         that the
>>            community can understand what's happening behind the
>>         scenes when a
>>            bug lays open without comment for a long time and what you
>>         can do to
>>            help. Your feedback is welcome.
>>            *
>>            Why Hasn't My Bug Been Fixed?*
>>
>>
>>            "I went through all the trouble of filing a great bug
>>         report and
>>            it's just been sitting there for months with no action, or
>>         it was
>>            closed out by the engineer. What's going on?"
>>
>>            The NetBeans team values your hard work in providing us
>>         feedback and
>>            reproducible test cases for bugs. In most cases, we
>>         address your
>>            bugs individually. But in some cases, there can be no
>>         action on your
>>            bug or an action you don't agree with. Here are a few
>>         reasons why
>>            this could happen, and some things you can do about it.
>>
>>            *Not Enough Time*
>>
>>
>>            The simple fact is that, like most large software
>>         products, we do
>>            not have enough time to evaluate and resolve all of the
>>         bugs in any
>>            given release. The NetBeans team concentrates on the P1s
>>         and P2s in
>>            any given release then fixes as many of the P3s as we can
>>         before
>>            it's time to ship. That means that some P3s get carried
>>         along from
>>            release to release.
>>
>>            *We Can't Reproduce *
>>
>>
>>            This is the number one cause of bugs not being addressed
>>         or being
>>            closed out. If we can't reproduce it locally, then it's
>>         very hard
>>            for us to fix it. However, we often have enough evidence
>>         that the
>>            problem does exist. Thus we leave the bug open to gather
>>         duplicates
>>            and other information in the hopes that some new reporter
>>         can help
>>            us reproduce it.
>>
>>            *Not in Stabilization Phase Yet*
>>
>>
>>            Often we're in the middle of new feature development,
>>         while the bug
>>            stabilization phase comes a few months later. This can
>>         lead to your
>>            bug not being commented on for a long time.
>>
>>            *Not Actively Developed Functionality*
>>
>>
>>            When NetBeans tooling for a certain technology is mature
>>         and the
>>            technology itself is not changing often, we try to make as few
>>            changes as possible in that area, since any change would
>>         require
>>            heavy retesting of the whole area. This can lead to bugs
>>         staying
>>            open in these areas for a long time.
>>
>>            *The Problem Isn't an Easy One to Solve*
>>
>>
>>            Some problems, while valid problems, are relatively minor
>>         but would
>>            require large rewrites of the present infrastructure. For
>>         example,
>>            line wrap in the editor was a seemingly simple change that
>>         we had to
>>            do a substantial editor rewrite to enable. But we left the
>>         bug open
>>            to track the votes and user interest in this feature until we
>>            decided it was time to implement it.
>>
>>            Other bug reports are for issues that we work on
>>         continuously but
>>            can still improve. The performance of project scanning is
>>         one such
>>            area. We often leave these bugs open because they contain
>>         valuable
>>            information on reproducing performance issues. But that
>>         doesn't mean
>>            no work is being done on those issues.
>>
>>            *The Proposed Solution Isn't Proper or Realistic*
>>
>>
>>            People often file issues because they would like to see the UI
>>            designed a certain way (for example, change a keyboard
>>         shortcut for
>>            a frequently used action). Others propose solutions to
>>         problems that
>>            are not realistic (make project scanning optional -
>>         NetBeans can't
>>            provide any IDE functionality for a project until it's
>>         scanned the
>>            project and knows what's in there!). In these cases, NetBeans
>>            engineers will close out your bugs as INVALID or WONTFIX.
>>
>>            *To Close or Not to Close? That Is the Question!*
>>
>>
>>            So what's better? To leave a bunch of bugs that you know
>>         you have no
>>            intention of working on open for release after release, or
>>         to close
>>            them out as WONTFIX, even if they are valid issues, and
>>         have the bug
>>            database be a closer reflection of what you are currently
>>         working
>>            on? In the past, we've just left everything open, but
>>         lately we have
>>            started closing out old bugs that have not seen any changes in
>>            several releases. If your bug gets closed out and you can
>>         still
>>            reproduce it, feel free to reopen the bug. This helps us
>>         to confirm
>>            that the bug is still valid.
>>
>>            *What Can I Do?*
>>
>>
>>            The easiest thing is to just add a comment to the bug and
>>         ask if
>>            there has been any progress. That will often (but not
>>         always) get
>>            the responsible engineer's attention and elicit a
>>         response. Other
>>            things you can do are:
>>
>>            * Be specific! The more you can help the engineer
>>         reproduce the
>>            problem, the higher chance that it will get fixed.
>>            * Vote on the issue. It's not a guarantee, but it is used
>>         in our
>>            decisions on what to work on
>>            * If you suggested a UI change that was rejected by the
>>         team, try
>>            configuring the UI to implement your change through
>>         settings and
>>            macros, or try writing a module that implements the UI
>>         change for you.
>>            * Submit a patch. Check out the First Patch program for help.
>>            * Take it up with the NetBeans Governance Board. If you have
>>            submitted a patch and there is a disagreement on whether
>>         or not to
>>            integrate it, you can ask the NetBeans Governance Board to
>>         mediate.
>>
>>
>>
>>
>> -- 
>> John Yeary
>> --
>> http://javaevangelist.blogspot.com
>> http://www.johnyeary.com
>> *@jyeary*
>>
>> "Far better it is to dare mighty things, to win glorious triumphs, 
>> even though checkered by failure, than to take rank with those poor 
>> spirits who neither enjoy much nor suffer much, because they live in 
>> the gray twilight that knows not victory nor defeat."
>> -- Theodore Roosevelt
>