This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 165288 - IssueTracker/bugzilla properties for NB-Projects
Summary: IssueTracker/bugzilla properties for NB-Projects
Status: REOPENED
Alias: None
Product: connecteddeveloper
Classification: Unclassified
Component: Bugzilla (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Stupka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-15 15:22 UTC by mikee11
Modified: 2010-03-11 05:01 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mikee11 2009-05-15 15:22:02 UTC
when you SVN-commit an entry (and open up the bugzilla section), you can't seem to specify the Bugzilla PROJECT.
That means you end up potentially searching a large multi-project bugzilla database when you really shouldn't have to.

So we need to be able to somewhere in there specify the PROJECT (or leave it BLANK to search the whole bugzilla repo)

--

once we go down that path, doesn't it make sense to in the NetBeans PROJECT, specify the Bugzilla PROJECT(s?) that is
associated with the Netbeans project? That way when you commit an svn entry, the bugzilla section is already properly
populated.
Comment 1 Tomas Stupka 2009-06-11 14:44:22 UTC
ondra > any ideas?
Comment 2 Ondrej Langr 2009-06-11 17:17:27 UTC
My assumption is that typically with a commit, you close an issue which has previously been opened in the IDE. (you've
opened that issue, seen it, fixed it and now you're commiting the changes). In this case, no online search is even run,
opened issues are cached locally. Ideal performance, real-time results, no necessary UI clutter. For majority of users,
the "project" would only be a useless information we request on them and which is in-the-way of their task. 

Closing as WONTFIX, if you think this assumption is wrong, please reopen.

Comment 3 mikee11 2009-06-11 19:18:14 UTC
lets talk about this a little more if thats OK.

There is the BASIC ability to "annotate and/or CLOSE" a Bugzilla ticket when doing an SVN commit. 

This is a cool feature, and very handy. (especially interim commits with notes to be added to the bugzilla ticket).

The RFE in question is to not just point/search/allow-selection of *all* bugzilla tickets on a bugzilla server, rather
just the ones associated with this particular PROJECT. (meaning that as part of the project-configuration file you could
associate (if you wanted) a particular bugzilla-SECTION/PROJECT. (thereby establishing a direct relationship between the
Netbeans-project you're working on, and the bugzilla-instances tracking its bugs)

If you're pointing at a bugzilla instance, that was used by only 1 project, obviously this wouldn't be a big deal.

--

I think you can hack this manually by creating a NEW bugzilla service for EACH NetBeans project, and "deep-linking" to
the instance/project as needed. Having a single bugzilla instance that is used directly by multiple NB-projects is more
common though, and providing some 1:1 bugzilla-instance<==>individual-NB-Project capability seems like a good option.

--

I hope I gave a better explination this time, but please let me know if its still not clear.

Comment 4 Ondrej Langr 2009-06-12 10:52:54 UTC
I think I see your point, thanks for deeper explanation. 

If this association would would be done in project configuration file and wouldn't affect UI, it doesn't concern me at
all and I agree it may be nice-to-have thing for someone. (Originally I thought your suggestion was about adding a
combobox allowing to limit the scope of a search to single bugzilla product/project). 

But it's a useless feature for vast majority of our users as they will not know about it and thus will not benefit from
it in any way.

We already associate NetBeans project with and an Issue tracker so that in the Issue field in the commit dialog, you
should only see issues associated with the bugzilla associated with the project. This association should be done at the
first commit. (Sidenote: it does not seem to work for me now, but that is probably a bug.)
Comment 5 mikee11 2009-06-12 14:03:46 UTC
sounds like the enhancement I was suggesting is something you guys had already designed under the covers -- I just
haven't seen it since its not working 100% at the moment.

but where/how does this project-to-bugzilla instance get defined? (is it by deeplinking when you setup the bugzilla
instance? Its not obvious to me how this happens (should happen).

thanks for having another look into this.
Comment 6 Tomas Stupka 2009-06-12 14:10:37 UTC
> sounds like the enhancement I was suggesting is something you guys had already designed under the covers -- I just
> haven't seen it since its not working 100% at the moment.
i guess what olangr was talking about is a feature that works only for kenai projects
Comment 7 Ondrej Langr 2009-06-12 16:06:18 UTC
Whoops, I'm sorry for the confusion. I'm so deep-dived in Kenai that my brain refuses to admit there's a word beyond it
;-). 

For non-Kenai projects this would definitely make sense. But instead of specifying this in configuration files (which
most people will not ever find), it would be great to figure out some "automatic" way of doing the association, so that
it would help all. But I'm worried this may be infeasible: even if you commit 10 times from one nb-project and always
change only issues from a single bugzilla product, it doesn't necessarily mean that those two are in 1:1 relationship. 
Comment 8 mikee11 2009-06-12 16:12:47 UTC
fair enough.

thoughts on:
1) in the properties tab, allow for a bugzilla instance/target (but it might be hard to find etc)
2) allow you to hit a "PULL_DOWN" in the commit pop-up, to restrict the search/realm there.
3) maybe some sort of restriction option in the bugzilla/service-definition setup? (allowing you to create
"single-bugzilla instance" bugzilla services that you can then 1:1 associate?)