MR> My question is: is this review sufficient, if not, where is it MR> written down, that it isn't? I'm especially aiming to the form of MR> this review. Bottom line is that it isn't. This turns into a nice argument every few years. In the past when I ran across one of these (i.e. back in the good old days when I actually read the entire package review mailing list) I'd double check and I pretty much always found something that was overlooked. Opening a discussion about how the review was probably insufficient was usually enough. - J<

MR> To be clear, imho there's no need to take back a granted review, the MR> packager of the reviewed package knows his job well. Again in the good old days, I was also processing most of the SCM requests, so I'd effectively stop the process until the review was re-done. Occasionally this meant that I did my own review. MR> I think, a review generates work to do for the reviewer. Well, theoretically it does. We have nothing to prevent someone from just setting the flag without actually doing any review work at all. Hopefully such stuff would be caught at some point, but really unless someone is actually looking over all of the tickets this doesn't happen. At best someone will notice that a package is in pretty poor shape, look up the review ticket and notice that it wasn't done well. But who has time for that? There are 350+ packages in the review queue. Still. - J<

On Wed, 08 Feb 2012 20:26:06 +0100, MR (Matthias) wrote: Please mention the ticket number. It may be that the spec file is short/simple and that the listed items cover most of what was necessary to review. I find it silly to even mention "name: ok". It is. There is no requirement for the reviewer to flood the ticket with a huge list of checkmarks about things that possibly don't even apply to a package. It doesn't make reviews better, and it doesn't make them safer either. That is because the guidelines aren't bullet-proof and not complete either. In other places, the guidelines are not detailed enough and only experienced reviewers understand the background. Btw, I think we've had cases before where reviewers, who have posted an overwhelming checklist, missed several items (or got them wrong). [not limited to %optflags, plugins in -devel packages, static libs, licensing, files in wrong subpkgs] We do. In the same way we trust our packagers. And still, some packagers *and* reviewers (re-)introduce packaging mistakes *after* a package has been approved. ;) Sometimes the changes in package git invalidate the review results completely, because a packager messes up the packaging. Fill a growing list of reviews where the reviewer has missed important items, and then let's figure out what can be done about that. Let's not punish good reviewers with tiresome bureaucracy. Do whatever helps you to gain confidence in approving a package. If you feel it's necessary to process a checklist and include that checklist, do that. Once you've posted such a list in a review, what would you do if another reviewer pointed out that you've missed a couple of unowned directories, for example? (note: that's still a MUST item in the review guidelines)