A couple of notes:

To start with: this RFC is more a description of a particular
implementation than a specification of its concept. Doing so very easily
end up in a discussion of the merits of alternative or near-miss
implementations, which is unnecessary and gets a bit tedious. But this
is just a minor observation.

Then, as I discern it, the underlying concept is very good, and perhaps
we could kneed the document towards a clearer specification of that,
primarily. The description of the implementation is then motivated by
the specification (rather than the opposite).

I understand the aim to be, to have an essentially fully automated build
system, whereby all package maintainers can make their packages be built
and included into their choices of distribution suites, as governed by
the "registered trust" of the maintainers by the suite administration(s).

That "registered trust" is a permissions database, telling which
maintainer (by virtue of a gpg key) may perform which operation (from a
predefined selection) with respect to which distribution suite (among
the predefined collection of suites).

[* Who are managing this trust database? What must a (prospective)
maintainer do to gain the build permission(s)? Is there a review
process, for revoking permission(s)?

[* Permissions are for different commands and suites; Is there anywhere
a need to extend the concept to a per-package permission?

[* The automation reaches out in some certain way to "places" where
packages reside; this aspect is a little unclear. Is there a single
hosting store, or multiple stores, that the automation inspects and
retrieves from? Maybe an architectural outline of a specified data flow
(or alternatives even?) would be useful?

** [Here the RFC would be copied in for inline commenting, if I had any] **


Ralph.