Nicolas Chauvet wrote:
2008/12/14 Thorsten Leemhuis <fedora(a)leemhuis.info>:
Let's talk about the "unreviewed" idea. (or quickly reviewed)
>From the infrastructure Point of View, the updates-testing
is what fit best the definition of unreviewed (testing) packages.
Because we can prevent this package from hitting stable-updates until
But repo reputation can also be an issue, eg if a user made
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
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
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
- Approved for stable , once everything is fixed from a packaging side.
This alternative review process shouldn't be the default review process.
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.