hard time finding packages really for review

[Michael J. Knox]

top posting, sorry..

What I find hard about reviewing is figuring out if a package is 
actually under review or not. I see a metric shit load of comments, 
suggestions and discussions on some FE-NEW submissions, but they remain 
unassigned amd in FE-NEW.

Sometimes I will skip over a package simply becuase I don't know whats 
going on. Some folks do the right thing and clearly state they are not 
reviewing the package, which is great.

The package status script would not be able to help in these cases. If 
people used bug blockers properly, then the script could help.

Michael

Patrice Dumas wrote:
> Hello,
> 
> I have seen floating around the idea that there was a need for reviewers 
> for old reviews. So I started with the packages in FE-NEW with no activity
> in eight weeks:
> http://fedoraproject.org/wiki/Extras/PackageStatus?highlight=%28package%29#head-6ebf09953da14bdd17d75280dba5b4cffb941077-3
> but I had a hard time to find a package really waiting for a review. In
> the end I ended up looking at all of them, and here are the statistics
> (I removed kmobiletools, accepted closed):
> 
> 7  packages are stuck in review for various reasons
> 11 packages are stuck because they are waiting for submitters
> 10 packages were stuck with a need of a reviewer
> 
> So we have only 10 packages for 28 (about 1/3) that are really waiting 
> for a review. This makes searching for a really open review quite 
> painfull. So I think we should do something to be able to discriminate
> the packages 
> 
> * stuck for various reasons except needsponsor, including 
> because of packaging guidelines blocking the review like recently some
> php reviews.
> * the packages stuck because the submitter has to take an action 
> but hasn't moved for, say, one month.
> * leave the other packages under review as is.
> 
> a possible proposal could be along blocking special bugs that would 
> change the background color in the trees like 
> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-NEW&hide_resolved=1
> to a given color. These colors could take precedence over the status 
> (like NEW, ASSIGNED...). It would be nice if it could also be seen on 
> top of the bugreport, but if it is only in 
> Bug xxxxx blocks FE-SUBMITTER-ASLEEP FE-NEW
> it would be right too.
> 
> I don't think it should be a must, but something nice to have. some
> members of the fedora QA team, or anybody else, could for example look
> from time to time on old reviews and make the blocks.
> 
> I don't care about that proposal, it is just an idea thrown, it might
> not be feasible, but I think something should be done to help find
> where reviewer can really act. 
> 
> Lastly, there could be a procedure for AWOL/MIA submitters similar than
> the one for AWOL/MIA maintainers, to allow submitters to replace 
> AWOL/MIA submitters and restart a review. This is allready done on a
> case by case basis, but I think a policy wouldn't hurt here, and having
> a classification of review stuck by submitter could help to find the
> AWOL/MIA submitters.
> 
> 
> 
> 
> 
> Here are the details if you don't trust my numbers :)
> 
> Review stuck 6:
> disagreament:
> fnord freedt
> 
> licence issue:
> acx-kmod acx-kmod-common
> 
> wondering about whether it is a good idea to include in extras or not:
> alsa-oss phpBB
> 
> needsponsor 1:
> gq
> 
> waiting for submitter 11:
> smixer smokeping sparse gitweb mondo lurker libpri magic socat
> fxload kdiff3
> 
> Waiting for review 10:
> xmms-musepack transconnect ardour pyscript Wcl linux-wlan-ng gpc
> vdr-osdteletext vdr-subtitles sqlgrey
> 
> --
> Pat
>