Peter Jones wrote:
It's very similar, but not quite the same, for a couple of
reasons. To
wit, Jesse's proposal mostly seems to focus on the repos being somewhat
transient - "Bob wants a repo to test something" - whereas I'm discussing
a longer-term purpose. Also, his is on a individual level, whereas what
I'm discussing would be more at a SIG level. That in some sense may make
implementation somewhat easier, by putting a damper on the rate at which
they need to be created and destroyed, and also might include some
oversight as to whether creating it is really such a good idea - but
making it a "is this completely bogus" sort of choice, rather than a
"does this fit in to our rigorous policies" kind of decision. This
would also help avoid the option-overload that comes with #3 on my
original example list.
SIG-level repos would work for stuff like KDE, but what about those packages
where a maintainer just wants to provide a new version, but there's no SIG
clearly responsible for the package? Many of our packages are maintained by
1 or 2 people, not by a SIG. For example, what about Gnash? I could stick
Gnash updates in the KDE SIG repo under your proposal, but I'm not convinced
that would be a good place for them. And what about packages which neither
clearly map to a SIG by its contents (which is the case for Gnash) nor have
a maintainer clearly attached to a SIG (which happens not to be the case for
Gnash, but for many other packages, it is, since we do not require
membership in any SIG to maintain a package)?
Kevin Kofler