Differences between revisions 6 and 7
Revision 6 as of 2007-10-26 19:30:58
Size: 8718
Comment:
Revision 7 as of 2007-10-26 19:34:32
Size: 8869
Comment:
Deletions are marked like this. Additions are marked like this.
Line 111: Line 111:
 * Uploads are done via HTTP with authentication (email address + password) so they can be received by the web framework (instead of an FTP server)

mentors.debian.net Todo/Feature list

The mentors.debian.net service is being partly refactored. This page is supposed to collect ideas and features.

Feature list

(this list may not cover all existing features)

General ideas

  • no binary packages (it is a developer service and we don't want complaints from end-users) by default
  • Emphasis on social interaction/networking
  • More interactivity - AJAX/AHAH - Web 3.0 ;)

  • Better looks of the site (steal from http://launchpad.net, http://xing.com, http://debian.wgdd.de/debian/, www.haveamint.com/)

  • User accounts for Debian developers/sponsors, too, so they can comment/score package and maintainers
  • Proper URLs (e.g. http://mentors.debian.net/packages/cream instead of http://mentors.debian.net/cgi-bin/view_packages?package=cream) - RESTful

  • Making information available to others through proper interfaces (JSON, XML, SOAP, whatever) - might help sponsors.debian.net - and document that interface properly ("mentors API")
  • Getting BTS information through its LDAP interface
  • More icons for better overview (http://www.famfamfam.com/lab/icons/silk/)

  • Clear start page with big buttons telling the purpose of the site (similar to http://flickr.com)

  • RSS feed on new uploads
  • search functions (sponsors, sponsorees, packages)
  • run the new site in parallel to the old site as a beta service (http://mentors.debian.net:5000)

  • make the Python code available (careful not to publish passwords in the repository)
  • proper documentation of modules, URLs, database schema in restructured-text format within the repository
  • make it generic so that other people can setup their own private repository servers
  • have a plugin architecture (to allow certain scripts or functions being executed at various times like when a package is uploaded, after it's checked, when it's sponsored, when someone leaves a comment etc.). That should allow people to extend the application in case they want a buildd-like function for automated binary package building.

Proposed tools, modules and languages

Assets (Database tables)

  • Users
    • package maintainers/sponsorees
    • Debian developers/sponsors
    • Database fields
      • Index
      • Real name
      • Email address (unique but can be updated)
      • PGP key (currently used for authenticating uploads)
      • IRC nickname on OFTC (so that users can be informed online if they wish)
      • Password (MD5 hashed)
  • User-Ratings (let other users voice their opinion on a certain maintainer)
    • Index
    • Timestamp
    • ID of the user this rating belongs to
    • ID of the submitter of this rating
    • Score (1=bad ... 5=good)
    • Text
  • Files
    • Possible files are .dsc, .orig.tar.gz, .tar.gz, .diff.gz
    • These are the files in the actual repository that are stored in a diretory tree on disk
    • Database fields
      • Index
      • Timestamp (when the file was placed in the repository)
      • Filename
      • Size
      • MD5 checksum
      • Package ID the file belongs to
  • Packages
    • Index
    • User ID the package belongs to
    • Name (could also be used as the directory name in the repository tree)
    • Description
    • QA Warnings (lintian errors, piuparts errors, native package, etc.)
    • Closes bugs (list of bugs to be closed by the upload)
    • Logfile (textual output from the import process to debug problems)
    • Watch counter (how many times the package has been looked at)
    • Download counter (how many times the .dsc file has been downloaded)
    • Seek Sponsor Flag (set to "true" if the package needs a sponsor - otherwise a sponsor is found already)
    • Announced IRC Flag (will be set to "true" to mark that the upload has been announced on #debian-mentors)
    • Comment (can be set by user - e.g. "Security update" or "Replaces package foobar")
  • Package-History
    • Index
    • Timestamp
    • Type (set of 'newupload', 'sponsored', 'deleted', 'comment', 'seekingsponsor', etc.)
    • Text (the actual content of the history entry)
  • Package-Ratings (let other users voice their opinion on a certain package)
    • Index
    • Timestamp
    • ID of the package this rating belongs to
    • ID of the submitter of this rating
    • Score (1=bad ... 5=good)
    • Text

Uploading/Importer

  • QA tests
    • syntax check of *.changes file
    • check if package is properly signed
    • check if maintainer is listed as registered user in the database
    • build test (perhaps through pbuilder - do we really need to spend so many resources? is it the scope of mentors?)
    • piuparts test (can we handle that with the resources?)
    • lintian checks (backport of lintian)
    • linda checks (backport of linda)
    • do the closed bugs belong to the package? (some packages accidentally closed other packages' bugs)
    • native package check
  • Uploads are done via HTTP with authentication (email address + password) so they can be received by the web framework (instead of an FTP server)
  • Removed files from previous package versions (only one version is kept)
  • Inform people who subscribed to the package
  • Pull orig.tar.gz from official Debian repositories if not included in the upload (is that really useful?)
  • maintainers should be forced to increase the package version/revision number to avoid confusion when different package contents had the same version/revision number (yes, this will be confusing at first)

Packages

  • Package list (http://mentors.debian.net/packages)

    • pagination (not displaying everything on the same page)
    • allow filtering (e.g. only show packages needing a sponsor)
  • Per-package page (http://mentors.debian.net/packages/foobar)

    • Closed bugs (clicking on a bug opens a popup getting information from the BTS over LDAP - ldap://bts2ldap.debian.net:10101)
    • Other packages from this maintainer
    • History
  • History (keep a history of uploads, comments, changes)
    • history is kept for all eternity - even for packages that were deleted already
  • Comments
    • if done comfortably this could replace the RFS-threads on the debian-mentors mailing list
  • Check if the package is already in Debian
  • Creating RFS boilerplates (filling out as much information as possible)
  • Is there a new upstream version?
  • Popcon score
  • How long has the package been waiting for a sponsor?
  • display information on copyright, upstream homepage if possible

Maintainers/sponsorees

  • Scoring (karma)
    • Every registered user can add an opinion
    • is the maintainer is doing well or not?
    • Add comments like "This user is constantly hijacking packages. Beware!" or "All the packages have been great." (like on eBay)
    • no anonymous comments - always show who wrote that
  • Information page
    • which packages does the sponsor have online
    • Scoring/Karma
  • allow changing GPG key

Sponsors/DDs

  • Let DDs/sponsors register/have accounts, too
  • List of preferences (programming langue, CDBS/debhelper, ...) so that maintainers can try to find a matching sponsor

Repository access

  • don't store the packages in an Apache-index-style directory tree but serve the files through ?FileApp (for more flexibility)

  • count downloads for statistics ("your package 'foobar' has been downloaded 23 times")
  • does anyone use mentors as a "deb-src" repository? or do we all use "dget -x"?

Background magic

  • monitor debian-devel-changes mailing list to see if packages were sponsored already
  • check if newer packages are availible in the Debian repository
  • announce new uploads on IRC (#debian-mentors on OFTC) - perhaps even /msg sponsors if they are online
  • warn maintainer about old packages (older than 3 months) / expire old packages (older than 6 months)

Developers

This is a list of people involved in the 3.0 relaunch of the mentors site:

  • Christoph Haas?BR Been there since the start. Founded the service years ago with Ivo Marino, Christoph Siess and D.K.Gebhart. Claims to always have done most of the work. Currently the only one working on the site, fixing bugs and doing user support

(add your name here)

The Subversion repository will be made available. Public: read-only. Developers: full read-write with username/password.

Include this

Some documents from the [http://workaround.org/mentors.debian.net/doc/ repository] need to be included in the above list.