New Package Process

[Greg DeKoenigsberg]

My biggest problems with the review process, aside from the obvious 
technical issues:

1. It's not clear who should be doing the reviewing.
2. It's not clear what they're reviewing for.
3. It's not clear why review is necessary.

To take these point by point:

1. WHO. This is why the bugzilla queue is so important -- it lessens the
burden of answering the question "who," because if the "NeedsReview" queue
is well-understood, then anybody who has spare cycles can review a
package.  I think that will help everyone, and as I understand it, this is 
the particular problem that Warren and dkl are working on now.

2. WHAT. Do we all agree what we're reviewing for?  Are we reviewing for
adherence to the packaging guidelines?  Are there hard criteria that can
be tested by tools, or are we simply looking for "little things" that only
experienced eyes can spot?

3. WHY.  Why are reviewing people's packages?  To teach them what's good
and what's bad?  To teach them in matters of taste?  Theoretically, a
package that isn't properly assembled should fail to build -- should we be
working to put some of this burden on the build system?  Is that
possible/feasible?

===

<grand_vision>

Let me sell a little bit of big picture here.

How will we scale this project to a million packages?  Because that's the 
goal.  The goal of Fedora Extras, in my mind, is to provide all of the 
software in the world to all of the people in the world.  Nothing less.  

Is that a ridiculous goal?  Of course it is.  But it's the ridiculous goal 
that gets me out of bed in the morning.

What is the *one thing* that stands *most directly* in the way of reaching
that ridiculous goal?  I'd say it's the fact that there are maybe 100
people in the whole world who *really* understand how to build good RPMs
-- and there are very few good tools to help.

If we are ever to solve the "million packages" problem, we MUST limit the
need for human review, and we MUST build the tools to help us do it.

Here's the review process as it stands now:

1. Novice packager submits crap package. 
2. Reviewer takes an hour to explain precisely why it's crap.
3. Novice packager fixes and submits somewhat-less-crap package.
4. Reviewer takes 15 minutes to explain why it's still a bit crap.
5. Lather, rinse, repeat until package is not at all crap.

Here's how I wish the review process worked, and how I think we should 
aspire to having it work:

1. Novice packager builds crap package with the assistance of 
fe-pkg-builder.
2. Novice packager puts crap package thru fe-pkg-lint, which points out 
large chunks of crap.
3. Novice packager fixes package so that fe-pkg-lint doesn't puke.
4. Reviewer points out why it's still a bit crap.
5. Reviewer files bugs against fe-pkg-builder and/or fe-pkg-lint.

To recap:

The goal of the Fedora Extras project should NOT be to teach everyone the
difficult art of building a good package.  That's solving the wrong
problem.  The goal, rather, should be to make that difficult art as easy
as possible.  Otherwise, the universe of packages will *always* be limited
by the number of people who are smart enough to work their way through our
arcane rules -- rules which *we* should be smart enough to figure out how
to hide.

And yes, having discussed this problem ad nauseum with RHN engineers, I
*know* how hard it is to solve.  Doesn't change the fact that it *is* the 
problem that *must be solved*.

</grand_vision>

So.  How do we start?  Or do we believe that it can't be done?

--g

_____________________  ____________________________________________
  Greg DeKoenigsberg ] [ the future masters of technology will have
 Community Relations ] [ to be lighthearted and intelligent.  the
             Red Hat ] [ machine easily masters the grim and the 
                     ] [ dumb.  --mcluhan
      Red Hat Summit ] [
         New Orleans ] [ Learn. Network. Experience Open Source.
     June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.) 
                       [ http://www.redhat.com/promo/summit/