[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]