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

1. Difference tool. This allows one to focus on the differences between two file trees. For example, one might want to compare two versions of a package and focus only on the differences. The definition of a difference depends on the implemented subtraction filters.
2. Groups. Implementing user groups inside of fossology is an indirect but critical requirement for 1.3 because tagging (the real 1.3 requirement) is dependent on having groups to administer tag permissions.
3. File tagging
   1. The ability to attach a tag (short (max 32 character) tag, plus a long text) to a file or container.
   2. Tagging requires permission for creating, attaching, and viewing tags. Access control at this level does not currently exist in fossology which is why we have a dependency on groups and a permission strategy.
4. Replace the copyright agent. A quick experiment showed that we can get better results with simple heuristics rather then the current naive Bayes. Development is on branches/new_copyright.
5. fix cp2foss authentication error that prevents bucket agent from getting scheduled.
6. Increase software Quality. This task involves a number of subactivites.
   1. 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.
   2. PHPUnit Test Framework Investigate the feasibility of using this suite of tools forunit testing PHP, performing code coverage analysis of php code and test automation.
   3. Code Coverage for C code Investigate and produce a process that allows the capture of code coverage data for our C code using LCOV and GCOV.
7. Separate text in UI to facilitate i18N for Stefan.

1. 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.
2. 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.

1. 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)
2. 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?:
   1. 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. DONE: Unpack performance.
   2. The current unpack agent cannot process some Microsoft proprietary formatted files. Look into how we do this on a Linux server. DONE unpack_microsoft_proprietary_formatted_files
   3. Since p7zip supports multiple threads and unpacks more than just microsoft install files, look into if it makes sense to replace some of the other utilities we use. In Progress replace some of the other utilities used
      1. The first step to this is to look at our install dependencies for ununpack. Then from that list, which could we remove if we used p7zip (since we already have a dependency on p7zip). So start by making a list of the ununpack dependencies.
   4. Are there libraries we can use instead the fork/exec'ing each unpacking utility? For all the commands we use, using libraries instead of the executables is something that could potentially, significantly, speed up ununpack. instead fork/exec with libraries in progress
3. Deprecate (bSAM) license analyzer and licterms. Either remove entirely or move to its own, unsupported, package.
4. 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. Pending Perfect the message and log organization
5. UI for bucket definition and management (new, change, delete) Not sure where this goes in the priorities.
6. UI cleanup. Work on inconsistencies and ease of use. Some problems are:
   1. 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.
   2. Micromenu can get very cluttered.
   3. Search should be an option at any browse level.
7. Display license changes by package version (moved from 1.2)
8. Display license differences on a per file basis between versions of any archive (rpm, tar, etc) (moved from 1.2). This includes Distro reports
9. Browse by collections. A collection could be all the uploads in a folder, or it could be a user selected set of uploadtrees. To impliment do an sql union of the collection, then proceed normally. This applies to all browsers (browse, nomos, buckets, copyright).
10. 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.

This list is not in priority order.

1. Remove copyrights from nomos scan.
2. Add to nomos licenses used by ninka and spdx. This includes exceptions.
3. Add to nomos, zend license.
4. Populate the license_ref table and ship it. Then nomos no longer needs to update it and it will have actual useful information.
5. 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.”
6. 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.
7. 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.
8. How can one tell who, when and from where an upload came? Add to ui-browse
9. Modify code to support the db server on a separate system. This has always been a design goal but has not been tested.
10. 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.
11. 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.
12. Need agent to remove orphan files from the repository. This can happen on a delagent failure.
13. Add license from kernel object modules (license from modsym) to license_file
14. New “Compare” checkboxes to compare different files/directories/packages/…
15. 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.

1. New scheduler
2. Modular plugins and agents. There are many advantages to separate optional package. Support for optional plugin installs.
3. Improved multihost configuration and installation.
4. Consider changing repo layout to work with “large” perhaps 16MB files kind of like hadoop. Using small files like now (avg size ~32k) makes repo deletes take forever and makes copying the repo take forever. For our repo, we could pack as many files as will fit wholly fit into ~16MB. Larger files would be saved as individual files. The whole point is to consolidate the tiny files to use fewer inodes and thus speed up delagent and repo copies.

All the mockups can be found here. Or just click on the individual mockups below:

1. Attachments
2. Package browser
3. File Browser
4. Browsing a package
5. Buckets
6. Copyrights, URL's, and email addresses
7. List of files containing a license
8. License browser
9. Package License History
10. Browsing Distro packages
11. Package Info
12. Top Menu items
13. Viewing a license
14. License Browsing with license differences

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

• Password reset capability. (from ScottL).
• (Mary/Bob) Improve postgres error checking and error reporting
• (Mark) improve reporting of UI test results.
• (Bob) Attachments The ability to attach an object (text, property, etc..) to a file or container. mockup
• (Alex) New machine learning license analyzer (based on sentence clustering). Currently we are calling this F1. If there are results from both this analysis and fo_nomos, the results will be combined for reporting. Part of this is to compare with Ninka.
• REST API - also look at thread started by Phil Martin the info in this thread needs to be added to REST API
• Binary analysis for open source discovery
• Document FOSSology recommended hardware configs
• Add load testing to automated test suite
• Implement automated nightly builds - should also include performance regression tests.
• Upload from version control system (CVS, SVN, PVCS) - From George Pace
• Write dependency analysis agent - note, being worked on at U of Victoria now
• Vulnerability tracking - note, being worked on by U of Victoria now

Low priority - could wait for 2-3 releases (or more)

• Share data between multiple repositories
• Get distros interested in using fossology to scan their codebase This is already happening with FreeBSD
• Generate meaningful URLs
• FO permission scheme needs improvement
• Integrate fossology data with other open source data providers
• Provide analysis to OSI License Proliferation sub-group
• Code clone detection
• Write kernel taint detector agent
• Define project release criteria
• Define project coding standards
• Improve text search Requires postgres >= 8.3
• Archived Reports - simple text file dump, PDF reports, eventually full web archive of all analysis reports
• Write tar agent - re-tar arbitrary parts of repo - don't have an owner/customer to support
• Add pie/bar charts to license analysis - fun to have, pretty pictures, not that useful
• Automated Collection and Presentation of FOSS Notices. Many of these suggestions are incorporated into v 1.3 tasks.
• 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