Package review backlog.

[Toshio Kuratomi]

Thank you Thorsten!  This list is really really great!

Thorsten Leemhuis wrote:
> Ideas for making things easier and better are there; they are afaics
> well known among contributors and the different committees that are
> responsible. Just nobody is working on them:
> 
>  * improve rpmlint and other tools to automate more of the checks to
> less the burden on the reviewer
> 
We also need to note which Guildelines rpmlint completely checks for,
partially checks for, and does not check for.

Licensing, for instance is a a case where rpmlint helps by verifying
that the license tag matches the abbreviations we specify but does not
verify that the source code only contains the listed license(s).

>  * make review exchanges easier; maybe even force/guide/direct people a
> little bit to do exchange reviews (e.g. a little bit like, but not as
> strict as "if you want to get your packages reviewed you have to review
> a package from somebody else first")
> 
I agree with this although I think "a little bit like, but not as strict
as" is the crux of the issue.  We want people to realize that there's a
bottleneck in the review process so they have a duty to try and help fix
the situation.  How much we lean on them is the big question :-)

>  * look more actively for new sponsors and be less strict when choosing
> them (like it has been in the past); we all make errors -- it's the
> ability to learn from them and to fix the errors once they got made
> 
I'm not sure this is the bottleneck.  Or at least, once we fully
integrate the next point:

>  * be less strict with sponsoring people like it was in the early Fedora
> Extras days in 2005. We can do that now that new packagers don't get
> access each and every package in CVS
> 
The technical work has been done for this.  It would be nice to see some
written guidance on sponsorship now.  ie: the old mindset is that
sponsorship is bestowed when people have shown that they are reasonably
competent with the packaging Guidelines and are responsive when someone
points out an error in their packaging.

With the tightening of what an initially sponsored person can do, how
should this change?  How can we promulgate the changed expectations when
we determine them?

>  * add one more level between new packagers and sponsors; soon-to be
> sponsors there could work together with new packagers and keep an closer
> eye on them; by that they could get work of the real sponsor and show
> their ability to become a real sponsor sooner or later
> 
This makes some sense.  I don't know how formal the additional level
needs to be.  It seems that it's more or less just for tracking purposes.

>  * let FESCo and the Fedora Packaging Committee work together to make
> review and packaging guidelines easier to understand. We have done that
> two times in the past iirc (once in the fedora.us days and the last time
> it iirc mainly was spot's work with some help from mschwendt, scop and
> some others in the early FESCo days before the FPC existed). I tend to
> say it's overdue to do it again. Guidelines for corner cases in that
> process should get moved to special add-on documents or sections that
> are hidden by default. That will make the main things easier to
> understand and remember. Otherwise we soon have guidelines that will
> look like a code of law/statute book that nobody really understands as
> knows, as they are long and quite hard to read. Maybe splitting the
> guidelines might make sense as well: a "this is how it works in general"
>  could be the quick ans easy start; a "here is how it works in detail"
> could serve as reference doc wher you have to look for the details and
> special treatments when it comes to perl/python/mono/java/...
> 
+1

I've been trying to get some momentum up with the Docmentation Project
to reorganize the Packaging Guidelines.  I think one of their major
wishes to help with that is getting a CMS.  That in turn depends on
finding something that works and also doesn't make people cry when
security considerations are presented (if someone knows of a CMS with a
good security record, please step up!  If it's written in python so we
can easily make it better, that's a bonus but not 100% necessary.)

>  * there are likely more ideas floating around...
> 

So one thing we need to do is figure out how to get this into the wiki/
Project consciousness/ worked on by someone.  The last one on the list
is something that is progressing slowly with Docs and FPC.  I'll make
sure I keep talking with docs about doing that.

Some could be good small programming projects (or GSoC if we get a
definition of what we want by next summer [I'm thinking rpmlint/package
review tool here])

A few of the items should be discussed and then taken to FESCo.  For
instance, when to sponsor someone into packager, uberpackager, and sponsor.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081012/2412143d/attachment.sig>