Upstream developers mainting there own package in Fedora and nothing else
David Timms
dtimms at iinet.net.au
Mon May 5 12:19:36 UTC 2008
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.
More information about the fedora-devel-list
mailing list