This list represents what we would like to do for v 1.3. We will be working on v 2.0 at the same time as 1.3. Our goal is to get all the high priority items done and probably all the “easy” items. The low priorities will get done if we have time (we are switching to time based releases). It's possible that we will get to none of the low priority items in 1.3. Whatever we don't do will become high priority in 1.4
-
Tagging. For example, tag individual files or containers. If container then the tag might or might not cascade to all it's files. A bucket could tag files. For example, it could tag all the gplv3 packages as “Need Review”. Then as they are reviewed, the reviewer would change that tag. This means tags are editable.
To implement tags like this (editable) we need user groups. So write access could be restricted to the group that created the tag, for example. Other ideas can be found here
File tags (moved from 1.2)
Improve(replace)the copyright agent. A quick experiment showed that we can get better results with simple heuristics rather then the current naive Bayes. Development on branches/new_copyright.
C code Unit Test and Coverage suite. Initial proposal, ideas or framework for how to use C code unit tests and C code coverage to improve our code quality.
Scheduler.conf does not get created correctly for a cluster. fosscp_agent and fo_notify should only be run on the scheduler host (localhost). Don't forget to include an entry for selftest, too.
NFS I/O performance investigate and improve. NFS file I/O is the largest bottleneck for agents, so what can we do to make it faster? Besides faster, making repo access more robust, easier to admin, and take less disk space would be big improvements.
Add/Modify licenses on-the-fly this would include a new permission level so that user can correct license and bucket data (other data as well). Perhaps this would update the real data record, but an audit trail could be kept of any changes. (reqt from sutula)
Improve the unpack agent. The unpack agent used by fossology extracts files from containers. A container is any kind of file that stores other files. For example, a ZIP file contains an archive of different files. Other types of containers include tar, ar,
ISO, and rpm files. Look
here for a full description of unpack agent. What’s wrong with the current unpack agent?:
The agent is SLOW. It can take days to unpack a Linux distro. Since Linux distros are of primary interest to the OSRB, fossology needs to be able to unpack distros in hours or minutes, not days. How can we take advantage of multiple CPUs (with the –m switch?) and agent systems to improve performance.
Larry is investigating this issue, and have done some jobs, the performance is improved. Unpack performance.
The current unpack agent cannot process some Microsoft proprietary formatted files (for example, .msi files). There are windows based command/utilities capable of doing this. Do any exist for use on Linux?
Larry will investigate this issue after unpack performance job. Unpack Microsoft proprietary formatted files.
Information/error messages are unhelpful, non-existent and difficult to find in the log file. Log meaningful messages with names of file being processed (if applicable) to a log file for a specific upload – NOT the general fossology.log file.
Deprecate (bSAM) license analyzer and licterms. Either remove entirely or move to its own, unsupported, package.
UI for bucket definition and management (new, change, delete) Not sure where this goes in the priorities.
UI cleanup. Work on inconsistencies and ease of use. Some problems are:
The way you queue a job that has already been unpacked is different depending on if it is a new scan or a rescan. Of course, most rescan's don't work, but that's an issue that needs to be handled by the new modular agent/plugin design.
Micromenu can get very cluttered.
Search should be an option at any browse level.
-
Display license differences on a per file basis between versions of any archive (rpm, tar, etc) (moved from 1.2). This includes
Distro reports Browse by folders. Do union of sql query of all uploads in a folder.
Identify binary packages and the source package they came from (Scott Lamons). The issue here is that the source may not be in the same upload as the binary. So when looking at a binary we need to have an option to choose a source and look at its scans.
From slamons: “We need a way to allow users to easily set up new accounts. It would be especially nice if they could log in using their HP email and NT password (or better yet, SiteMinder
single sign-on session). As it is, it is not at all obvious that you need to set yourself up a new account before you start running analysis.”
Integrated error information. Our current method of logging EVERYTHING to fossology.log makes it difficult to debug issues and view log messages/errors for a particular upload or file.
Add capability for reanalysis without breaking data persistence ie. do new analysis without removing previous analysis results. This can be used, to compare new and old analysis results, and to insure that report url's are persistent. 1.2 implemented data collection for this for nomos and buckets. The UI needs to catch up and allow one to select the data set they want to see. The code is already in ui-buckets.php and ui-nomos-license.php (search for FUTURE). But we need to decide if this is the interface we want.
How can one tell who, when and from where an upload came? Add to ui-browse
Modify code to support the db server on a separate system. This has always been a design goal but has not been tested.
Remove pfile.pfile_liccount from schema and code (common/common-license.php, plugins/agent-license.php, plugins/agent-license-reanalyze.php, plugins/ui-license.php. This was an experimental feature that mistakenly had code checked in around it.
delagent needs to be more robust. Much of the delagent db updates should probably be done with cascading deletes on the upload. Perhaps cleaning the filesystem should be a separate agent that could be done on a periodic basis? Because of the concurrency problem of deleting unused files from the repo while another agent it adding them, delagent should never run concurrently with unpack or probably any other agent.
Add license from kernel object modules (license from modsym) to license_file
New “Compare” checkboxes to compare different files/directories/packages/…
Create a user interface to create bucket pools, bucket definitions, scripts and anything else needed, along with a prompt & screen to rerun analysis with your newly defined bucket pool.
Current method is too ugly.
Spend more upfront time planning new features, estimating time to implement/test and identifying impacts.
Develop new “disruptive” code on a branch so as not to cripple top-of-tree builds, install and testing.
New scheduler
-
Improved multihost configuration and installation.
All the mockups can be found here. Or just click on the individual mockups below:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
This list captures “everything else” that we would like to work on but do not have scheduled, planned, or owned yet. This is the kitchen sink, as in “everything but the kitchen sink.”
High priority - within the next two releases
Low priority - could wait for 2-3 releases (or more)
-
-
-
-
-
-
-
-
-
-
-
Archived Reports - simple text file dump,
PDF reports, eventually full web archive of all analysis reports
-
-
-
rpm
spec file analysis - we have pkgagent and pkgmetagetta that determine info about rpm's, but maybe there would be some value in analyzing .
spec files we find. ununpack will unpack source rpm's that it finds and we'll already have some info from them. but maybe we'd find loose .
spec file in source trees too. We need more specifics.
Easy way to install buttons/links on micro menu to
run system utilities/scripts on a file. For example, .ko files could have an nm link, and a modinfo link. The script may need a way to determine if it should be added to menu or not. For example, nm applies to object files, but modinfo only applies to .ko.
See
Archive for a list of completed tasks
