RFC: staging repo

[Nicolas Chauvet]

2008/12/14 Thorsten Leemhuis <fedora at leemhuis.info>:
> Hi all!
...
> Should we open a "staging" repo in addition to the free and nonfree repos
> which would hold unreviewed packages that could be improved in the staging
> area in a wiki-like style and then easily transferred to the proper repos?
Thinking of another repository remind me this mail:
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-October/001507.html
That been said, the main keyword here is "unreviewed" {packages}
whereas it is replacement {packages} for the other idea.


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.
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.


> I for example had asked Gérard Milmeister (gemi) if he wanted to submit
> PovRay to RPM Fusion nonfree (he has it in this gemi repo), as I seldomly
btw, Why wouldn''t you take care of it ?

>> I would have rather have someone already involved with rpmfusion take
>> over the package. My repository IS in fact meant for other people to
>> use the packages as a basis for inclusion in "offical" Fedora
>> repositories.  [...]
The problem behind this, is the lack of RPM Fusion contributor.
We are more and more contributors nowadays than in livna,fresh,and dribble time.
But there is also lot of work until "all packages" got reviewed and
imported properly.

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.
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).

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.
 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.

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.


Nicolas (kwizart)