RFC: staging repo

[David Timms]

Nicolas Chauvet wrote:
> 2008/12/14 Thorsten Leemhuis <fedora at leemhuis.info>:
> Let's talk about the "unreviewed" idea. (or quickly reviewed)

>>From the infrastructure Point of View, the updates-testing repository
> is what fit best the definition of unreviewed (testing) packages.
> Because we can prevent this package from hitting stable-updates until
> properly approved.
But repo reputation can also be an issue, eg if a user made concerted 
effort to have the rpmfusion resources build bad packages, that are 
available (even if not by default) the fallout from bad press would 
still be felt (rf provides backdoored mediaplayer...)

> Once the package is approved, the package is already imported in the
> same cvs and the changes are tracked.
> That way we can avoid to split one more repository.
As I understand it, opensuse has a fully public build service, and it's 
something that rpmfusion could potentially do.
There could be some pre-requisites like:
- spec must pass rpmlint with no errors nor warning.
- home page must exist (200 + content).
- builder only retrieves the SourceURLs - hence must currently exist.
- must create a rpmfusion fas account
I'm thinking here of things that can be tested with automation, rather 
than needing lots of manual intervention.

However, from the security point of view, isn't there a potential for a 
builder to be vulnerable to bad packages ? And to DOS, unless / even if 
fas account is required. Also, might need tonnes of extra space (as 
Fedora itself has trouble with from time to time).

> This put our current "review process" in question:
> In some cases, the fact that review process take time isn't that bad,
> this help raising issues that couldn't have been discovered with the
> "every day" maintainability from already approved packages. Now we may
> need to split what prevent from a package to be approved than what is
> the most optimized shape for a package to be.
Having only limited experience with this I know that with the extra work 
it takes to get an already working package into Fedora/RPMFusion shape, 
that once I have that "Package Approved" statement, it's like a sigh of 
relief. What's in the repo is what has been reviewed, and changes 
shouldn't be undertaken lightly.

If I got green light at first attempt, there would be no incentive for 
me to continue to work to get the package into tip-top shape, once it is 
already in the repo.

Contrast this with say mozilla development, which seems to occur within 
bugzilla as patches, that then get reviewed and super-reviewed before 
the developer is allowed to commit the changes.

> Because having a package been tested in updates-testing could also
> allow feedback's better than having it in the staled review queue (and
> eventually provided within another repository).
Instead of -testing, perhaps a better name could be "under-review" or 
similar to strongly indicate the lack of peer review.

> I think we could have packages semi-approved when:
> - A package license is compatible, and redistribution is allowed.
>  (rar isn't certain, yet).
> - Installation of the package doesn't disturb/break the system
>  (first wxsvg-freeworld wouldn't have been approved for example)
> - The package can build from source.
>  (xdtv cinelerra-cv could have been allowed)
> - Package works at runtime with it's major features.
> 
> Once theses point are OK, maybe that could allow to remove the
> "package review lock" having packages semi-approved. Then, the work
> needed for having the package approved will need to be written in the
> review.
> But that will still requires an initial submitter and a reviewer, with
> the difference that everyone could improve the package under the hood
> of the initial submitter.
> 
> We could have different level of APPROVAL:
> - Approved for cvs: the cvs is created, package is imported, built,
> but not provided in RPM Fusion repositories.
I think that having specs / patches in revision control is important 
because then you can more easily check diffs between last and current 
fix. It's also a big step for first time packagers with no/little 
revision control system experience.

>  This could allow to share the workload needed to raise the package to
> be at least usable or when few minors improvements would be needed
> from the spec files.
> - Approved for updates-testing: same as with cvs, but package remains
> in updates-testing. eventually announced for a more public audience.
> At this time general usability have been proven, but it still need
> improvements.
> - Approved for stable , once everything is fixed from a packaging side.
> 
> This alternative review process shouldn't be the default review process.
I like the idea that specs, and patches live in cvs from inception. I've 
made the effort to package, and then managed to lose my development 
version in the past.

> What make me think gemi POV isn't uncommon, it that the current
> scheme. The initial submitter do all the work to raise the package in
> shape. With the semi-approval process, the workload can be shared with
> various "proven contributors" and package import could be easier.
It's the experience of those "proven contributors" that needs to bleed 
out to us other packagers. I tend to learn / remember more from a 
suggestion to do X, maybe checkout how reviewer did it with package Y, 
and actually doing the change myself. If further people don't gain those 
skills, how can the community be grown ?

Another query, do we expect people to actually at least build on their 
own machine (with either Fedora or EL) before submission ? One way to 
encourage that is the current review request where you are asked to 
provide the rpmlint of your locally built .src.rpm and rpm's.

I do see a lot of "can I submit this" sort of queries, where the user 
has found the spec for some other distro, and has no idea what or why 
that wont be suitable for Fedora/EL + RPM Fusion, has probably never 
tried to build it. I'm not saying that existing code shouldn't be 
used/built upon - more that we pride ourselves on quality packages... 
and this does take some effort to understand the guidelines.

DaveT.