You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code coverage: The 0.7.0 release has 91.4% coverage. Goal for 0.8.0 is to increase the coverage to 94% (issue Increase test coverage to 94% #577) - P1 PARTLY DONE
Expand use of documentation index (issue Expand use of documentation index #598) - PARTLY DONE COMMENT: This is a continuing effort so should be part of every release)
Refactor the tests so that we run more tests in interactive mode. This would significantly increase the speed of running the tests (most of the time for each test is pywbemcli startup).
Indications: QUESTION/KS: How important are indications and subscriptions to pywbemcli. I do not know
Explore possible use of tab completion usage with options variables and more command arguments. Today we have implemented the ? as a sort of artificial completion mechanism where these wildcards trigger some sort of lookup and present a list of possible results. Thus INSTANCENAME has a lookup if the keybindings is simply the "?" wildcard. Could we consider extending these to a) use tab completion in place of wildcard lookup (note that it would have to work in both command line and interactive cli modes) b) use the wildcard completion on more options (issue Implement completion of cmd line arguments and options of the command line #482) NOTE: The click project is progressing with completely redefining the auto-completion functionality (see click issue #1484 and a corresponding pr in progress). This means that we should take this work into account in defining what we want to accomplish and how to accomplish it for auto-completion.
Use the wild card concept now used on INSTANCENAME for the value component of other options and arguments:
server profiles and server centralinsts.
--namespace option
--name general argument to get name of persistent connection
Class tables.However Karl has not come up with a logical table equivalent to date. SUGGESTION: Look at Jim's and Karl's existing table displays and try to sort out how you handle things like overrides, qualifiers, etc.
Consider a machine-readable form of output that would allow command redirection at least at the shell level. Note that click itself does not really support the idea of redirection in the interactive mode (output of one command available as input to the next command) but we could use the click context as a way to pass results to input in the interactive mode (Which would make the command mode different than the interactive mode). Some examples of usage might be: Run a command to get the namespaces and then run anther command on all of those namespaces.The easiest idea for this is the processing of things like connection names, instancenames, classnames, and namespace names. or lists of the same.
Maintaining server state in interactive mode:
Consider maintaining some information between commands in the interactive mode beyond what is maintained by the Server class. Remember that profiles and namespaces are maintained in the Server class instance as long as that object exists. ex. classes by namespace. Thus we would extend our pywbem_server to allow it to maintain more information. The information could include at least class names by namespace (issue Cache classes or at least classname retrieved from a server #483)
In the interactive mode consider maintaining connection information in memory when different connections are selected so that if a server was selected, any previous current connection would not be completely cleaned (today we clean each connection as it is selected). Some ideas are stash of class names or classes by namespace. Maintain the concept of a current thing; current class, current instance that would be applied to commands (issue Cache all information about an active server when switching connection #484)
I made some specific comments above but in general, I think we should define a specific set of goals for 0.8.0 that we feel are important to users and use those as the drivers for each release. I think each version should have at least one key goal that means something to the user, not just to us developers. Typically this is a new or significantly changed piece of functionality which is what sells to users.
Thus, I need to poll at least a couple of users. ACTION KS_
Thus each release always should:
Satisfy some of our internal improvement goals:
a. Improve or at least maintain coverage.
b. some specific things we need to do for better development, testing, etc. (ex. refactor tests to use make them faster)
c. Work to keep pylint down.
d. Implement functional improvements that we have thought out. We often see the tool better than the users do so we see new functionality, usage, documentation better than they might so we should incorporate our new ideas. But these are not the drivers, it is the user requests that drive each release.
e. Improve and extend documentation.
Additions from users as required or desired.
P1 At least one issue that is driven by users ( new functionality, improved usage, etc.) and should be important and visible to them(reason why they want to upgrade)
With item (3) above being the key although that requirement may well drive the items in 1 (especially item d). Thus some user requirement may well drive us to do things like caching to meet the requirement.
Finally, I propose that we try to limit the number of new things for each release and turn around releases more rapidly; smaller but more increments.
Bug and issue status:
Release content of 0.8.0:
These issues have a target release of 0.8.0.
Bugs:
Cleanup:
Testing:
Ease of use:
Documentation:
COMMENT: This is a continuing effort so should be part of every release)
Speed up mock load for large loads. (issue A faster Mock loader would be nice #689) P1 - DONE
Mock script interface to register dependent files (issue Mock script interface to register dependent files #748) - DONE
Content beyond 0.8:
These issues have no target release. This list may not include all issues without release target
Other Functionality:
Cleanup:
Testing:
Indications: QUESTION/KS: How important are indications and subscriptions to pywbemcli. I do not know
Ease of use:
NOTE: The click project is progressing with completely redefining the auto-completion functionality (see click issue #1484 and a corresponding pr in progress). This means that we should take this work into account in defining what we want to accomplish and how to accomplish it for auto-completion.
Output formats:
Maintaining server state in interactive mode:
Profiles:
Other ideas:
The text was updated successfully, but these errors were encountered: