CytoscapeCommons

Proposal

Provide some infrastructure for plugin developers: automated builds for plugins, maybe even wiki/bugtracker/version control hosting.

Background

Some cytoscape plugins are neglected and even for the most popular ones it is tedious to find their version control system / sourcecode, and in many cases they don't have a wiki or a bugtracker.

Use Cases

• automatically build and test all plugins every time cytoscape core code changes. This will give immediate feedback to cytoscape core developers on how much pain a proposed change in core apis will cause for plugin authors
• Lower the number of neglected / abandoned plugins, which are not updated for newer cytoscape releases by allowing other contributors (not the original plugin authors) to update it
• Increase the correctness of plugins by encouraging automatic builds and unitttests for them.
• Provide a way for submitting bugs and feature requests for a plugin

  (preferably even with the AutomaticBugReporter tool)

• Provide a straight-forward way to start developing a plugin: a simple way to sign up and get the infrastructure ready in a simple way. (Note: this might be as simple as having a tutorial that walks through the steps needed, we don't have to provide a one-click solution.)
• Provide a place where peer-reviewed papers related to a plugin can be listed / linked to.
• Make it easy to link from the plugin's UI to the wiki page of the plugin: allow plugins to have an 'about' dialog which has a link to the wiki page.
• If maven is used for a plugin, the site generated with 'mvn site' should be automatically built and linked to the project page. This should be linked with the similar site pages of the dependencies of the plugin (for example, the core bundles).
• The javadocs that are automatically built for a plugin should be linked to the javadocs of the core bundles / the dependencies of the plugin

Implementation Plan

Outline and describe the process and major issues related to implementing this proposal. Illustrate your plan when possible. Try this free online tool for making diagrams -> Best4c (draw; save; then insert hyperlink into this page)

There is basically two options:

1. provide our own hosting. This means creating a google code / sourceforge-like site. This might be a lot of work, or it might be as

   simple as setting up drproject or trac or something similar.

2. Don't provide hosting for wiki/version control/bugtracker, just provide automated builds. Point plugin developers to google code, and write easy-to-follow tutorials to set up a google code project and tie it in with cytoscape's automated build.

With 2), we only need to extend the plugin metadata format (plugin.props) to include the necessary metadata

Advantages of 1): possibly easier to tie in plugin's bugtracker into AutomaticBugReporter, or to move tickets from cytoscape's system to the plugin's system (i.e. reclassify a bug submitted to cytoscape.org as a bug in some plugin).

Project Management

Project Timeline

Provide a timeline for implementation. Insert a graphic if you can. Try this free online tool for making project timelines -> Help-u-Plan (create a new chart; modify; right-click to save gif; then attach to this page)

Tasks and Milestones

Outline the major milestones and tasks involved in implementation.

1. Milestone 1: find out possible disadvantages of 'don't have own hosting' option

   1. Task 1: check whether tickets can be moved from cytoscape's system to a google code project's tracker

   2. Task 2: check whether AutomaticBugReporter will be able to submit tickets to a google code project's tracker

2. Milestone 3: rethink plugin.props: what parts of it will be handled by OSGi / P2

   1. versioning will apparently done by OSGi instead of the plugin.props

3. Milestone 2: set up automated builds for plugins

   1. configure automatic build system
   2. create/configure summary page that shows results

4. Milestone 2: write / extend plugin developer's documentation

   1. document how to optimally configure this with Eclipse / other IDEs (include things like setting up mylyn to manage tickets from IDE, if possible)
5. move code from csplugins directory of svn to this new system

Project Dependencies

• AutomaticBugReporter (not required dependency, but these two RFCs complement each other.)

• automated builds for 3.0 core bundles

Related RFCs

• AutomaticBugReporter

Similar sites

Other open-source projects have similar sites for library/module/plugin authors. We should look to these for ideas and possible alternatives:

• trac has a site for trac plugins at http://trac-hacks.org/ this provides a common wiki, svn, bug/ticket tracker. There is no autobuild / common automatic testing as far as I (DanielAbel) see. They use a single trac site (naturally) which has some special settings to support such a sub-projects-like structure. These settings are somewhat kludgy, trac is not really designed (for now)

  for supporting multiple projects well. (https://www.drproject.org/ is a fork where supporting multiple projects was one of the explicit requirements, but I am not familiar with it that much)

• python has http://pypi.python.org/pypi which a freshmeat-like site for python packages, storing meta-information and links. There is also a seperate effort to do automated testing at

  http://www.pybots.org/ where some major python-using packages (frameworks and big libraries) are automatically rebuilt and tested whenever python-the-language-implementation changes.

• django has a freshmeat-like site at http://djangoplugables.com/; the convention appears to be to use google code for django modules / plugins.

Comparison of hosting alternatives

i.e. hosting the wiki,version control and tickets. Not automatic builds.

See comparison of free hosting places on wikipedia The following is a quick summary based on our needs:

• google code:

  • api for manipulating google code issues

  • has webhooks post-commit hook (for triggering build)

  • feeds of project updates that the plugin site on cytoscape.org can aggregate

  • scripted uploads might be handy if we want to push back build artifacts to the project (although it most likely won't be needed)

• github:
  • uses git (is it user-friendly? windows support?)

  • good api, especially the ticket api will be useful (for AutomaticBugReporter)

  • has webhooks post-commit hook (for triggering build)

  • default page of a project (http://github.com/<username>/<projectname>/tree/master) is too 'code-centric': it shows tree of files (git-browser) first. Wiki-view (http://wiki.github.com/<username>/<projectname>) would be a much better default page for linking to from cytoscape.org.

Links

• launchpad (used by Ubuntu and now opensource) has some cross-bugtracker linking features, i.e. connecting bugreports in different bugtrackers. Similar cross-bugtracker features are in development for the debian bugtracker

• Some sites implement webhooks (see above) which can be used (if needed) to trigger builds (if we don't want to set hudson to poll). Hudson should still poll since most sites won't make many guarrantees about delivering the notification via a webhook.

• http://gna.org/projects/forgeplucker/ might be useful to extract information from project sites hosted elsewhere

• http://www.ohloh.net/ and https://openhatch.org/ might also be relevant (they extract and catalog information from various project pages)

• A possibly interesting discussion of usability and design of such forge-like sites: http://sheddingbikes.com/posts/1299555462.html (via http://news.ycombinator.com/item?id=2299748) -- Fur the ui design one would need to consider the interfaces presented to the developer (who uploads code) and the user (the scientist who uses the plugin).

Issues

• Does cytoscape want to provide our own hosting for wiki/bugtracker/version control, possibly reinventing google code / sourceforge?
• Some plugins are published first in peer-reviewed papers and the authors wouldn't want the still-in-development newer version to be in a public place before the paper is published. Does the system need to explicitly support such "the public code is only the last stable version, current development is done in another, non-public repository" workflow?

Comments

• On providing meta-data about version control / bugtracker access: simply extending the plugin.props format to include fields for a version-control url (like

  svn+ssh://grenache.ucsd.edu/cellar/....; this should be general and not subversion-specific, so that plugin authors can use other version control systems; debian has a very general syntax for this) and a bugtracker url (just a http-link, I don't think there is such a convention as with version-control systems) would be enough. These fields could be trivialy shown on http://chianti.ucsd.edu/cyto_web/plugins/index.php and it should be pretty simple to extend the cytoscape's automatic build system to pull the sources and test the plugins as well.

• Add comment here…

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.