Infrastructure/PackageDatabase
From FedoraProject
Contents |
Fedora Package Database
.png){kind=small}
The Fedora Package Database aims to consolidate the information on the packages present in Fedora Package Collection. It will allow us to perform queries on packages and their maintainers as well as some of the administrative tasks associated with them (branch requests, etc.)
Code
Code for the package DB is in a bazaar repository. Check it out using:
bzr branch http://toshio.fedorapeople.org/bzr-repo/packagedb/fedora-packagedb-devel
Test Version
There are two test servers up for people to look at. Development Snapshot is there for people who want to see what's currently being developed. This instance may be broken at any given time as it's what we're actually working on and testing out. Version 0.2 of the PackageDB is deployed for people who want to look at what's working now. This server will be synced with development whenever the development tree is runnable. As of 15 March 2007, this tree has a feature complete GUI. I'm working on writing the backend that communicates changes to the database to the cvs repository and bugzilla.
Documentation on the Wiki
- Roadmap Lists the steps we need to take to implement the PackageDB. As we evolve what we want in it, we'll evolve milestones and featuresets we want by FC7, FC8, and beyond.
- Schema Has the schema for the package DB. The schema is written for postgresql.
- Goals Lists the things we want the package database to do for us.
- Notes on how to integrate with koji , the new build system.
Goals of the Package Database
NOTE: This page needs to be reorganized and reformatted.
These below are a few higher priority items that we keep discussing as needed in FESCO meetings.
- per-package per-branch fine grained ownership
- multiple owners possible
- package groups, subscription, notification
- views of packages, change history and associated bugs
- tracking of MIA owners, auto-nag, timeout, notification
- tracking of neglected packages, timeout, notification
- tracking of orphans
The above would allow things like:
- Build a package that breaks deps of other things in the distro. A background job detects this, and automatically notifies owners and whoever subscribed to watch affected packages.
- Security team could know at-a-glance what is being neglected and step-in.
- per package rpmlint exception, so that a script can be created which as part of the build on the buildserver runs rpmlint on the created rpms and fails the resulting packages if they give any warnings/errors not on the exception list.
Later we will be able to add things like:
- All of the other informational metadata that wasn't required by the above but would be useful to view and search. This includes stuff like dependencies.
- ACL access grant and revocation by owners at the package/branch level (this will become more important as we move closer to merging Core and Extras)
- Feature Tracking like IPv6 support (Josh Boyer's idea)
Other Ideas and Possibilities
- Possibly an improved package review process outside of Bugzilla. (Warren is skeptical about this one but putting it here for further discussion.)
- ability to have maintainers be included/excluded from secondary arch notifications.
- An easy way to get at data remotely -- e.g. some sort of SOAP / XML-RPC / LDAP interface to query.
- This allows us to submit build requests via scripts which talk to the Package DB.
- Manage comps files or other groupings (troves?)
- Manages notifications:
- RSS feed of changes to a package.
- Manage email notifications like extras-commits (and finer grained as well). So commit email would go to the package DB. Package DB would then disseminate to the extras-commits mailing list and people watching the package in particular.
- Being able to watch another contributer: Is this best done in the package db or the accounts db? If the accounts db, then notifications from here have to be sent to the accountsdb for further processing.
- Inheritable collections (collection foo is a subset of collection bar)
- ACLs on building as well as committing
- Ability to mark a build as having passed a QA check.
- ExcludeArch
- Upstream Versioning policy:
thl: abadger1999, would it possible to hae a field that stores a free text that
describes how upstream releases new ersions??
thl: e.g. something like "foo 1.0 and 1.2 is the stable branch, foo 1.1 and 1.3
devel"
abadger1999: If it's free text it should be easy to include something like
that.
thl: that would make it possible for a release manager to look at that and say
"hey, you build a devel package from a new upstream branch for a stable
package; is there any reasons to do that?"
thl: I'm not sure if that worth the trouble
thl: it was just an idea
abadger1999: It might not be worth the trouble but it is possible.
abadger1999: The problem being that 1) the data is entered by the packager
anyway, 2) it can't be a required field as some projects don't
have any versioning policy, 3) being free form, it won't be easily
parsable by a script.
thl: abadger1999, well, just keep it in mind; maybe something like that could
be helpful later
abadger1999: But it might help for people wondering why foo 1.3.3 has been out
for three weeks and we're still packaging 1.2.8
- Down the road it might be nice to provide a end user interface. Allow end users to: Thumbsup/Thumbsdown rate, make comments, contact the maintainer, go to a filled in bugzilla form to submit a bug for the package, provide testing feedback for test versions, etc.
- Sponsored information - https://www.redhat.com/archives/fedora-infrastructure-list/2007-April/msg00178.html
- Have a page that shows which packagers are active in EPEL or a certain Fedora release, something like the current EPEL |Contributor Status
