Re: some background on bugfixing in NetBeans

Hi Rob,
just to add a detail to the scan problem, there is a Source > Scna for
External Changes action already, since 6.9.1 I guess.
At least this problem should be fixed for you already.

Regards

On Thu, Sep 29, 2011 at 11:01 AM, Rob Ratcliff <[email protected]>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]>
>
>> 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]]
>>> *Sent:* Tuesday, September 27, 2011 4:24 PM
>>> *To:* [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]>> 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
>
>
>


-- 
Michel Graciano
Summa Technologies do Brasil Ltda.
http://www.michelgraciano.com
http://www.summa.com.br/
http://java.net/projects/genesis
http://java.net/projects/copypastehistory