ReleasePlanning

From SPCTools

Revision as of 17:52, 6 September 2012 JoeS (Talk | contribs) (→4.6.1 To Do) ← Previous diff		Revision as of 21:55, 10 September 2012 JoeS (Talk | contribs) (→Under Consideration) Next diff →
Line 12:		Line 12:
	== Under Consideration ==		== Under Consideration ==
		+
		+	* '''Feature ''Idea''''' - Transition petunia from using tandem.params.xml to tandem.params. While I understand in Petunia its historically been called tandem.params.xml and I'm loath to change this because of the impact. Why? For two reason. The first is I expect very shortly we'll be shipping at least one more search engine with TPP (comet) and it doesn't have a "comet.params.xml" file. Secondly on regis we've always (since I've joined ISB at least) called it tandem.params. Now I don't pretend to think we should make our users conform to us, I do however think we need to recognize that internally we support a large array of search engines and we've taken to naming all of the parameter files as <search>.params. To name this omssa.params.xml, inspect.params.xml, etc would be incorrect as these aren't always in xml format. Now I guess for those formats that aren't in xml we could create one but I don't think that's a great approach. Instead I propose following what I've done on regis, which is to use the native parameters file format when possible and in the cases were there isn't one (just command line parameters) use a very simple format that consists of just including all of the command line parameters.
	== Legacy Items ==		== Legacy Items ==

---

Revision as of 21:55, 10 September 2012

This page is intended to assist in release planning by tracking new feature requests/bugs/improvements etc for TPP.

4.6.1 To Do

• BUGS: issues brought up at http://www.viva64.com/en/b/0156/
• BUG: PTMProphet executable isn't installed on linux
• BUG: lorikeet uses hardcoded paths to the html and javascript directories on the Apache server (e.g. ISB/js/lorikeet.js) instead of using the TPP_WEB Makefile variable.
• IMPROVMENENT: pepXML_v117.xsd has changes that should probably be rolled into v118
• Merge ProphetModels.pl trunk changes back into branch
• BUG: segmentation fault and patch to src/Parsers/Algorithm2XML/Tandem2XML/TandemResultsParser.cxx by DT
• BUG: fix PTMProphet crash that occurred during the training class

Under Consideration

• Feature Idea - Transition petunia from using tandem.params.xml to tandem.params. While I understand in Petunia its historically been called tandem.params.xml and I'm loath to change this because of the impact. Why? For two reason. The first is I expect very shortly we'll be shipping at least one more search engine with TPP (comet) and it doesn't have a "comet.params.xml" file. Secondly on regis we've always (since I've joined ISB at least) called it tandem.params. Now I don't pretend to think we should make our users conform to us, I do however think we need to recognize that internally we support a large array of search engines and we've taken to naming all of the parameter files as <search>.params. To name this omssa.params.xml, inspect.params.xml, etc would be incorrect as these aren't always in xml format. Now I guess for those formats that aren't in xml we could create one but I don't think that's a great approach. Instead I propose following what I've done on regis, which is to use the native parameters file format when possible and in the cases were there isn't one (just command line parameters) use a very simple format that consists of just including all of the command line parameters.

Legacy Items

 Fix iProphet models page ("performance" models are missing)
- Add "Bruker" files option to msconvert in Petunia
- Fix pepxml2html (View Peptide hits) peptide link for SpectraST results
- peptidexmlhtml2 : does not work with AA highlighting option (mark_aa=)
- Add some filtering options to Pep3D  (specifically: view only +1 ions)
- Add QuickMod to speclibs page?
- retire getSpectrum -> use readMzXML
- incorporate psm2pdf
- include t2d support(?)
- Petunia: option to convert to mzXML using msconvert
- Petunia: launch all external links in blank/target window
- Reindex mzXML: new file with old name; rename old to: old-index or some such
- Petunia: option to run xinteract jobs as separate (instead of combining into a single analysis)
- Petunia: select pep.xml files only for input to Decoy Models pages
- Petunia: auto cd to dir and strip out full path if all files in same dir (shorten command line)
- Petunia: rename Mascot file on download
- Move /tmp/ directory under tpp-bin (Windows)
- Petunia: Add TPP version check (ping server) --> usage stats
- Petunia: add full filters to msconvert(??)
- Petunia: change tab graphic when jobs are done?
- PepXMLViewer: implement "preferences" tab: choose ions series, spectrum viewer, etc... ?
- PepXMLViewer: no pep-pro probability link in iProphet results
- Libra also needs some love (ability to curate ratios would be a great start...)


== From Henry (perhaps he already checked this in?) :
Following up on this discussion, I would like to propose the following. (This is not urgent since our course doesn't use OMSSA or any of the newly-supported engines, so it doesn't need to be in the release soon.)


1. Change xinteract to run RefreshParser before PeptideProphet.

This takes care of the protein name issues for OMSSA, and makes sure that the NTT and NMC fields are there and calculated correctly for PeptideProphet. Some search engines don't fill in those fields and cause PeptideProphet to crash.

The flip-side is mainly inefficiency. If the user decides not to keep all search hits regardless of probability (i.e. not specifying -p0), then this means RefreshParser unnecessarily refresh a bunch of wrong identifications that won't be in the final pepXML file anyway. But then again, given that nowadays PeptideProphet often relies on the protein name (whether it's a DECOY or not), it seems safer to ensure that the protein names are right -- even for the wrong hits -- before we run PeptideProphet. Also, with the new implementation, for most files RefreshParser is so fast that I don't think it will make much difference in running time anyway.

If the user doesn't want to refresh, he/she can always turn off RefreshParser (-nR option).


2. Have InteractParser detects if the search engine is OMSSA, and if so, apply the fix_pyro_mods_ option automatically.
This goes without saying. The only thing is the user doesn't have to turn on the option manually. I don't know if other engines have the same problem. If so, it's easy to add them to the list.