merge reviews

[Kevin Fenzi]

On Thu, 8 Jul 2010 19:47:41 -0400
Jeff Garzik <jgarzik at pobox.com> wrote:

> Cute re-ordering of events, there.  No, after repeated experiences
> with seeking reviews, including this most recent one mentioned
> elsewhere on this list, and seeing others on this list repeating
> review requests, I was inspired to poke around to see why responses
> were so uneven.

IMHO, lack of reviewer manpower and some people dumping large numbers
of reviews into the queue without contributing reviews back. 

> Looking at the process with fresh eyes, starting from
> https://fedoraproject.org/wiki/PackageReviewProcess and moving to
> https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests one
> sees a chaotic mess of package reviews, both assigned and unassigned,
> not really moving forward at all.  Looking closely, you see a lot of
> packages that seem of worth, but that set is crowded by review
> requests for ancient packages like redhat-menus or kernel.

Yeah, as mentioned, try: 
http://fedoraproject.org/PackageReviewStatus/

instead. I think I have changed the wiki to point to this instead, but
if you spot it still listed, please change it. 

> In an ideal world, every package in fedora/devel would get a full
> package re-review prior to each release.  But with finite resources
> limiting that, it seemed to me that triaging long-dead bugs for
> long-merged packages was a reasonable and helpful thing for the Fedora
> project.  By all appearances, nobody else was bothering with these
> things after several years went by.

Yeah, I agree that ideally we would be able to re-review existing
packages, but sadly, the manpower is just not there currently. 
I don't think triaging merge reviews is a good idea though. They aren't
harming anyone, and slowly people are doing them, so why not let them
stay? 

> If people want these obviously unloved, ignored review requests -- not
> even an rpmlint or ping in many cases -- to stick around, that's fine
> with me.  I thought I was being helpful, but easy enough to leave
> things alone as well.

Thanks. I would like for us to come up with some kind of plan for
these, but nothing is decided yet. It's best IMHO to leave them open
for now. 

> My hail review was proceeding, and I wanted to make the process a bit
> easier for the -next- person wanting a review.  Apologies for the
> ruffled feathers.

No worries. 

> The process itself is intimidating, because the wikis demand that a
> prospective reviewer wade into a completely unorganized swamp (BZ URLs
> linked-to from above URLs), hundreds of review requests, with next to
> zero information about where one's review would be most helpful.  To
> an outsider, it must seem like quite a mess, with completely unknown
> chances for success/failure.

Yeah, we could look at organizing some more for sure. There was a
"Package review sig" that tried to start up at one point, but as far as
I know it never got anywhere. 

Perhaps things like using priority/severity would be nice... you could
then mark reviews that are needed for new features as high, or things
that are leaf nodes as low, etc. 

Anyhow, more things to try and work on. ;) 

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100709/29636b60/attachment.bin