Hans de Goede wrote:
Michael Schwendt wrote:
> On Mon, 05 May 2008 10:27:14 +0200, Hans de Goede wrote:
...
>> This review is special as the upstream developer is
submitting the
>> package, and he has stated that for now he has no interest in doing
>> other Fedora work.
>> Ok, we currently don't really have any special rules for
an upstream
>> maintainer becoming a maintainer of its own software within Fedora,
>> but this is definitely something we want.
I think it carries huge risk.
While the upstream person knows a lot
about making their development work in many places {eg from rchive, deb,
rpm}, becoming intimately familiar with Fedora's {solid} methods is time
consuming and difficult. I would anticipate that it would also lead to
such people wanting to once write the build anywhere {rpm} spec. It is
clearly simpler reviewing a spec without half of the spec being "if ...
not SUSE ..." sort of thing, and I feel eases QA effort. But I'm no jedi
packager, nor reviewer.
> Any packager plays with fire if he touches
> things other than his own packages. And even if new contributors in a
> special group are locked down to their own packages, access to the build
> system is the crucial point.
True, I forgot about a number of ways to make any package wreck havoc
once in the repo, so someone truely malicious can wreck havoc as soon as
he/she can push packages to the repo.
So a person who could cvs commit his package
spec changes but little
else, could require a co-maintainer not involved with the upstream
project, and preferably a long standing trusted fedora package
maintainer to be able push to repo {any}, and perhaps even to request
builds.
Perhaps the process would be {automated by the build/push system} as:
- commit cvs change
- request build
- build system forwards the request to co-maintainers, including commit
changes.
- co-maintainer approves build if sees fit, else explain {eg you are
trying to introduce a root kit}.
- request push
- push system forwards the request to co-maintainers, including commit
changes.
- co-maintainer approves push if sees fit, else explain.
I was thinking a scratch build could be allowed, but given that the
result is accessible by others, that still leads to the potential for
gaining bad rep if/when someone takes advantage, and a tester gets done
{even if the build isn't signed and pushed}.
Is it only trust that stops any sponsored packager pumping out
accidentally or purposely bad packages ? {I forget whether there is a
formal procedure involving experienced others after the commit, build to
get a package pushed.}
DaveT.