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.
Summary: | Provide way to inform user about status of module on AU | ||
---|---|---|---|
Product: | platform | Reporter: | Milan Kubec <mkubec> |
Component: | Plugin Manager | Assignee: | Jiri Rechtacek <jrechtacek> |
Status: | RESOLVED WORKSFORME | ||
Severity: | blocker | CC: | jchalupa, mmirilovic |
Priority: | P1 | ||
Version: | 4.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
Milan Kubec
2005-05-12 08:38:31 UTC
There should be also some way in the dialog to filter out modules of particular status. It's not planned in new AutoUpdate UI (http://ui.netbeans.org/docs/ui/update/update.html), consult with UI team possible change of UI spec. Closed as WONTFIX because no anticipate when fix it. There is a workaround: each module can info about its stability join in module's description. Sorry, but missing feature is the reason why people file enhancements. If there is UI Spec without such feature then the spec must be fixed, IMO it's missing important part. So please reassing to responsible HIE person and let them fix the spec. This RFE is based on experience of real users. Adding such info to the description text is not enough because not everybody reads such info. We need some exclamation mark, different badge, changed color or something like that. People are just unknowingly mixing modules of different stability level and it has bad consiquences. "This RFE is based on experience of real users" - Milan could you add a link or smt else to this VOC? E.g. following thread discusses that: http://www.netbeans.org/servlets/BrowseList?list=netcat&by=thread&from=100390 But it's not the first time when users selected some modules on AUC and after downloading them and installing them IDE was unusable. I think that we should warn them before doing it. First, there is currently no flag to be set to indicate stability of a module. IMO, this is understandable as the definition of stability may differ between the vendor and the potential user. Thus, a module marked as stable can include critical bugs, there's no way to prevent it. I don't think that classifying modules at this level is a good idea. It would be just another flag that people would fail to set properly. The way we categorize modules by their to-be-expected stability level is by staging them on different update centers. However, Alpha, Beta, Stable, etc. UC is just a label. There's no notion of update center content stability hardwired anywhere in the infrastructure. The assumption is that users will figure out what Beta and Alpha means. In fact, for stable releases, we only provide Stable and Beta which is disabled by default. Still, some users tend to enable it and install all modules they can find, which may result in poor performance of the IDE, not necessarily stability problems. The only solution I can think about is to provide a way to associate a clear description of the purpose of each update center type and show it when people configure/enable/disable the respective update center. More ideas welcome, but I think we'd really need UI designers to help us out here. Also note that the existing UI at least alows the user to see which update center they are getting the module from. The UI spec for the new client doesn't show the source update center anywhere. It just shows the list of modules available on all enabled update centers regardless of their declared "stability" levels. This might be worth revisiting in the new UI design. One way how to prevent user from selecting all on AUC and installing it would be to remove the button for adding all available modules. That would make it a bit more difficult to add all and user would need to select every module she wants. But it seems the new UI of AU client uses different way or selection gesture. I think it works now. |