New Package Process

[Ralf Corsepius]

On Wed, 2005-04-27 at 11:45 -0400, Greg DeKoenigsberg wrote:
> On Wed, 27 Apr 2005, Michael Schwendt wrote:
> 
> > I would really prefer if "architecture specific Fedora community
> > developers" filled the role of package co-maintainers. Else we would play
> > the "if it builds, publish it" game and offer something, which has not
> > been tested at all.
> 
> Which is potentially bad, I agree -- but not guaranteed bad.
>
> Let's play this game.  I'll present a scenario, and everyone pile on and 
> tell me what's wrong with it.
> 
> 1. A *very* lightweight *initial* package acceptance process, in which we 
> determine:
>   a. No obvious maliciousness;
>   b. No obvious IP/copyright issues.
> 
> 2. A policy of "build the world".  Every package in the build system, we 
> build.  If it passes, it goes into the "untested" bucket.  This bucket 
> is also a repo, for those who dare.
> 
> 3. A mechanism for "final review" that marks the difference between "a
> package that builds" and "a package the builds and is any good".

Excellent, I was about to write almost the same when your mail
arrived :-)

Some considerations, which IMO hasn't had enough attention so far:
* I don't see a need why packages need to be maintained by single
individuals, they should be maintained by collaborating maintainers.
i.e. I am opposed to "package sponsoring" and to "assigning packages" to
individuals, because this doesn't encourage collaboration.

* reviews should have as "many eyes" as possible. IMO, fedora.us has
demonstrated that bugzilla is well suited to maintaining a package's
state, but is not suitable a main tool for package reviews.

* How about post-release QA? Bug reporting or (in worst case) even
package withdrawal requests?

>   And 
> let's think creatively about this final review: does it need to be a 
> single person who says "this is ok, I bless it"? 
I am in favor of a "voting system", e.g. a system that requires several
"ready for release" votes before a package can be released.

It would help prevent cases of individuals "pushing something half-bred
through" - Cases not 100% free of this suspicion had happened on
fedora.us (Of cause everybody will deny this allegation ;-) )

>  Or could it *also* be a 
> threshhold?

>   For example: we could say that any package that is installed 
> 100 times from the untested repo, without anyone voting against it, 
> is automatically promoted to the "tested" bucket.
Well, this criterion has very little significance. 

Firstly, the number of installs/downloads doesn't mean much, secondly,
not all packages are of equal interest/have the same size of audience.

>   This would provide two 
> paths: one path for packages that people are watching over, and a parallel 
> path for packages that people aren't watching over, but are still using.
> 
> Is this foolish or wrong in any way?
Do you mean having a repo of unreleased/testing/prerelease packages and
one of "officially released" packages? This would make sense.

Ralf