Chris Weyl wrote:
So here's a couple thoughts -- it would have taken more time to type
it out than to show the table relationship in dia, so here goes:
http://home.comcast.net/~ckweyl/fedora_package_db.dia
And yes, it's just a sketch :)
It also comes to mind, do we have actual requirements for what we want
this database to be able to do? e.g. just track packages & owners,
include builddeps, etc, etc?
I'm glad that people are talking about possibilities of how to implement
this, but we should step back and first think about what are our goals,
what do we actually want out of this? I think a package database system
would eventually encompass all kinds of information, but initially we
must prioritize implementation of things that we need and dependent data
structures.
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.
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)
Warren Togami
wtogami@xxxxxxxxxx
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
