> When you push the source to the git-tree, we will need to update the kmenu
> location. It currently installs to:

I don't mind adding new packages. I have a long list of candidates I'll post.

Yet when adding new packages I urge using a check list to ensure the new package meets current Trinity standards and not the shoddy standards of kde-look.org and sourceforge.net KDE3 packages.

Basically, I busted my ass the past month fixing a horribly broken and embarrassing help handbook system. I am not about to let that hard work disintegrate every time we add a new app.

Here is a starter check list. I derived this check list from my recent work with the help handbooks, which exposed a lot of crappy and lazy work by the original developers as well as other bugs.

New package addition check list:

1. Create a bug report (enhancement request) for any new candidate package.
   That way anything listed below that can not be resolved has a place holder.
   Do not proceed past this step unless a bug report is opened.

2. Convert as necessary to current TQt3 requirements.
   This process needs to be openly documented to encourage other people to perform some of the work.

3. Verify the package builds on at least three different distros.
   Typically Debian-based, RPM-based, and then an independent such as Arch or Slackware.

4. Verify a help handbook exists.
   * If none exists, then add a "We Apologize" shell handbook.
   * Verify the shell handbook template is updated to reference the new app.

5. For existing help handbooks, review the header information:
   * Update the DocType declaration.
   * Update internal entities (for example, &kde;->&tde;).
   * Do not add internal entities to general.entities (tdelibs).
   * Add copyright information for &tde-team;.
   * Add author information for &tde-authors;.
   * Update release date.
   * Update version.
   * Remove versions from handbook title information.
   * Ensure all header information satisfies current layout standards.

6. Verify the help handbook opens when selecting the handbook from the Help menu.

7. When secondary help handbooks are included, verify the additional handbook is available in the Help menu.
   Look at the kate Help menu as an example (kate plugins handbook).
   * Verify the additional help handbook populates the help handbook table of contents.

8. Verify a Help button is available in the configuration dialogs.

9. For certain configuration Help buttons, verify the help handbook opens to the correct handbook section rather than the top of the handbook.
   * Create additional *.desktop files to support opening to specific handbook sections.

10. Review existing *.desktop files:
   * Categories key must satisfy existing launcher menu structure.
   * The app populates only one launcher menu category.
   * Superfluous menu options are silenced in the launcher menu (such as kbarcode).
   * The Icon key references an icon that actually exists.
   * The icon appears in the launcher menu.
   * The icon appears the help handbook table of contents.
   * The DocPath key references the correct location of the help handbook
     The correct location is index.html and not appname.html.
   * Both a Name and GenericName key are defined to satisfy Description/Name and Name/Description menu users.
   * Verify Trinity supports new or obscure mimetypes specified.

11. Verify i18n files are reviewed or added.

This is a draft check list.

-- 

Darrell