Developing new features

(the following lists my opinions (assaf's), based on personal experience, and is not official savannah views, wish-lists or future plans. There is no guarantee any of the listed ideas will ever be accepted or implemented, or even considered worth-while.)

New features are welcomed! Do send ideas and patches.

See also HowToBecomeASavannahHacker.

Savannah is unique among code-hosting services in that it dates back to September 2000, and hosts code that dates back to 1986. It supports cvs,svn,bzr,hg,git repositories, rsync access, mailing lists with 15 years of archives, and more. It is also a primary hosting service for official GNU packages, and is used by veteran, experienced (and very opinionated) people.

Savannah values Software Freedom above all else, which has some implications regarding features which are availble on other websites (e.g. heavy use of Javascript, or enabling SaaSS).

As a result, savannah as a whole tends to be conservative regarding changes. Please keep that in mind when suggesting new features.

a list of ideas which I think are interesting, in no particular order:

  1. Automating project evalution: a program/website which takes an archive of source-code files, analyzes them and produces a report. A working beta is available here: http://gnueval.housegordon.org. Source code is here: http://git.housegordon.org/cgit/gsv-eval.git/. The code could use a lot of clean up, testing, and improvements.
  2. Developing a light-weight web interface to post bug reports to the GNU bug tracker http://debbugs.gnu.org. Note that the Debian DebBugs team strictly opposes to such web-based interface, insisting only on email. But with Savannah, we have an advantage: users are logged-in, and savannah knows their email address. It also knows the list of valid projects - thus, a webinterface could simply be a wrapper around sending an email from the savannah user.
  3. Running savannah services locally. Not only the web-frontend (See 'Working on Savannah website' in HowToBecomeASavannahHacker), but all the different savannah hosts. Documentating how to configure then locally, and/or set them up from scratch will help future administrators and contributors. Especially: setting up a 'sandbox' environment for DebBugs.
  4. Migrating the web-pages of hosted projects from CVS to Git. See more details initial discussion here: http://lists.gnu.org/archive/html/savannah-hackers-public/2014-11/msg00001.html,
  5. Improving the list of requirements for hosting projects, to complement HowToGetYourProjectApprovedQuickly. see http://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00045.html and http://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00025.html and http://lists.gnu.org/archive/html/savannah-hackers-public/2014-08/msg00040.html
  6. Rewriting the PHP code using modern frameworks. WARNING: this has been suggested/discussed/attempted many times in the past. Tread lightly.
  7. Phase-out the PHP-based trackers (the bugs/support/tasks interface) - either in favor of the current bug-tracker (DebBugs), or evaluate other possible solutions (BugZilla/Mantis/RequestTracker/Fossil/Others). This must include a way to preserve access to existing items (with the exact current URL). See http://lists.gnu.org/archive/html/savannah-hackers-public/2011-09/msg00000.html
  8. Redesign/improve the web interface, make it prettier and more accessible, while keeping it inline with GNU's priorities and values (no JS, no tricky CSS, viewable on non-graphic browsers, etc.).
  9. Developing 'sandbox' environments for web-pages updates, and for DebBug learning.
  10. Complement GNU Hydra, with continuous-integration/testing on multiple POSIX platforms. perhaps using pretest (disclaimer: that's a project I develop). Integrate with Savannah or GNU projects.
  11. Per-project Wiki, perhaps using Jekyll (need to verify savannah-policy related issues with this).
  12. Provide a Free-as-in-freedom build environment (or instructions to create such build environment) for Windows and Mac OS X platforms. See http://lilypond.org/gub/.
  13. Pruning the wiki pages, removing some cruft, merging similar pages and splitting too-long pages. See HowToAdminThisWiki.
  14. Explore allowing non-fast-forward commits on non-master branches, both from technical POV and from Savannah-policy POV. See: http://lists.gnu.org/archive/html/savannah-hackers-public/2015-01/msg00011.html
  15. Provide source-code browsing interface, integrate with GNU projects (using GNU Global or OpenGrok or other).
  16. backend project management (e.g. creating new git repositories) is orchestrated by cronjobs periodically querying for database updates (see SavannahInternals). Explore other methods (e.g. queues?).
  17. Create development/testing envrionments replicating the production one, enabling faster development (perhaps access to non-administrators).
  18. Importing and Exporting trackers items (bugs/support/tasks). Perhaps a conversion tool from 'trackers' to MBOX format compatible with DebBugs (i.e. work towards migrating all trackers to DebBugs?).
  19. Git-related improvements (hooks, forks, clones, etc.): see Task List section in Git. See also discussion about enabling non-fast-forward commits at http://lists.gnu.org/archive/html/savannah-hackers-public/2015-01/msg00011.html
  20. Cleaning up the savannah backend perl/python scripts:

    1. don't hard-code /etc/member.conf.pl in sv_membersh (or store it elsewhere).
    2. Make the perl script self-locating for the Savane perl module.
    3. Or better yet, get rid of the Savane perl module.
  21. Create a status/health-check dashboard website, with checks described in StatusMonitor.