[debexpo-devel] Concept work nearly done
Jonny Lamb
jonnylamb at jonnylamb.com
Wed May 21 15:25:31 CEST 2008
Hi all,
I suppose this is the first "status" email with respect to the SoC. It
hasn't properly started yet, and I won't really have too much time to
start until my final exam is over, which is the 30th May.
To introduce myself, my name is Jonny Lamb and I am working on debexpo as
part of the Summer of Code this year. I can be contacted through this
email address, although I would very much prefer any questions or
information that are not private go to this list so that others can
add their views, and so messages get archived. I read my emails far
too often, so unless something technically goes wrong, I will read, and
reply to, your email quickly. My IRC nickname is "jonnylamb" on
irc.oftc.net.
Ticket creation
===============
I have been doing a bit of debexpo research recently and have been
filing tickets in the tracker[0] to track each milestone. Comments on
those would be thoroughly appreciated:
http://debexpo.workaround.org/trac/report/3
I haven't been overly verbose in the descriptions as I wanted to get
all the items into the tracker so I could easily expand on it later when
I think of additional things to add. Also, at the moment, these tickets
are primarily just for me! :-)
Database
========
I also have designed the database schema and it can be viewed here:
http://jdl.ducs.org.uk/misc/debexpo-db.png
Please tell me if you see anything missing though. I wouldn't be
surprised if I've completely forgotten about something! A quick run-down
of the tables, in no order:
- users -- registered users on the system
- user_verification -- a string that is used in verifying a user. If a
user has verification string here, the user is not active.
- user_countries -- list of valid countries
- package_info -- "info" on a package version. This will contain output
from plugins like Lintian.
- package_versions -- this is so there can be multiple versions of a
package uploaded at once, and so the package keeps a history of
uploads.
- packages -- simply package in the repository
- package_version_files -- files (diff.gz,dsc,orig.tar.*) in a package
version.
- package_comments -- comments that other users give to packages.
- user_metrics -- user package preferences (e.g. prefers CDBS over
straight dh)
- ppa -- this is basically somewhere to store a name for a PPA as I
think using a user's email address in the URL is a little sick. This
could go into the users table I suppose, but that would mean having
a redundant column when PPAs are disabled, and this way allows PPAs
to be more pluginable.
- ppa_packages -- contains source package information
- ppa_package_versions -- contains version information for a package in
the PPA. This way there can be multiple versions in the PPA
- ppa_package_binaries -- information about binary packages
- ppa_package_sources -- information about source packages
Feel free to ask if you are unclear about what any table attributes are
for. I do intend to properly document the table structure nicely when
it's in stone. I'm no database guru, so I just want to make sure my schema
isn't on crack! :-)
Some notes:
* I would have liked the PPA functionality re-use some of the
package_* tables (I.e. instead of ppa_package_versions, using
package_versions), but unfortunately, as far as I understand, I
won't be able to use SQLAlchemy's nice relational features (E.g. [0]).
Please correct me if I am wrong.
* There are many attributes (users.type, package_info.severity,
packages.section, etc.) that I originally linked to other tables, but I
decided for the sake of simplifying the database to keep these fields
pointing to constants set in the code. After all, these values are
unlikely to change much, if at all. (Perhaps this is a call that the
countries table should be a constant dictionary?)
0. http://www.sqlalchemy.org/docs/04/documentation.html#datamapping_onetomany
Routes
======
Additionally I have set out a list of most URLs required. Feedback
appreciated on whether these are nice enough names, and of course,
whether the URL scheme I'm thinking of is sane:
/ welcome page
/my/ account modification
/my/packages/ my packages currently uploaded
/register/ register new user
/packages/ list of packages
/packages/maintainer/ list of maintainers
/packages/maintainer/user at user.com/ show packages of user
/packages/section/ browse sections
/packages/section/python/ show packages in "python"
/packages/potential/ sponsor's potentially ideal packages to upload
/package/packagename/ show packagename info
/rss/package/packagename/ RSS feed of updates to a package
/rss/packages/maintainer/... RSS feed for specific maintainer
/rss/packages/section/... RSS feed for specific section
/search/ search the site
Repository
==========
Trac currently isn't hosting any debexpo code, because none has been
written yet! That will hopefully sorted very soon when I actually start.
If you want to see the old debexpo code that Christoph started, I have
hosted it on my gitweb (for an unrelated reason, but now proving
useful):
http://git.jonnylamb.com/?p=old-debexpo.git;a=summary
Summary
=======
I realise this is a supremely long and boring email, but I would prefer
to get these things correct before starting! :-)
Thanks,
--
Jonny Lamb, UK jonnylamb at jonnylamb.com
http://jonnylamb.com GPG: 0x2E039402
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://workaround.org/pipermail/debexpo-devel/attachments/20080521/00076dae/attachment.pgp
More information about the debexpo-devel
mailing list