Re: Upstream developers mainting there own package in Fedora and nothing else

[David Timms <dtimms iinet net au>]

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.