F24 Change for PDC

Ralph Bean rbean at redhat.com
Wed Nov 4 01:05:39 UTC 2015


On Tue, Nov 03, 2015 at 11:32:11PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Nov 03, 2015 at 11:28:06AM -0500, Ralph Bean wrote:
> > Hey all,
> > 
> > I prepared a F24 Change proposal for PDC here:
> > https://fedoraproject.org/wiki/Changes/PDC
> 
> Looking at the list under https://pdc.fedorainfracloud.org/rest_api/v1/,
> there's a large overlap with pkgdb.
> Wouldn't it be better to augment pkgdb with the necessary bits
> and pull directly from there, instead of creating a new db
> which needs to be synchronized?

That's certainly an option.

In my opinion, we're better served by splitting the functionality out
into two different services.  As things stand, pkgdb is 1)
package-centric in its data model and 2) self-service oriented in its
UI.  On the other hand, PDC is 1) product-centric in its data model
and 2) admin-facing in its UI (really, just API).  There is some
overlap, yes, and it results in some implementation questions as
mentioned in the F24 Change doc.

FWIW, we don't have to use all of the models that PDC provides.  For
example, it has a table for modeling changesets -- git commits -- and
while there is an item in the Change document to populate.. it might
not be worthwhile to bother.

The latest incarnation of pkgdb is pkgdb2 (the one we've all been
using for over a year now).  There were a few reasons for rewriting it
over pkgdb1 -- one of them was that it was built on old frameworks
that needed to be retired, but another was that pkgdb1 had grown all
sorts of features that seemed convenient to bolt on over time.  We
split all that out into various things since then (appstream handles
application metadata, fedora-tagger handles those package-tag things,
etc..).  I'd like to resist the temptation to return to growing the
responsibilities of pkgdb if we can, and instead try to draw clearer
boundaries between more focused systems.  I.e., system A models our
packages and ACLs, while system B models our products and deliverables
(with help from the package modeling system).

Now that I think about it, pkgdb2 did grow a new "admin actions"
feature over the last year... which is another story of its own, I
guess.  :)


More information about the rel-eng mailing list