Fedora Merge Review: xrestop
Initial Owner: email@example.com
I would be happy to review this package. Look for a full review in a bit.
OK - Package meets naming and packaging guidelines
OK - Spec file matches base package name.
OK - Spec has consistant macro usage.
OK - Meets Packaging Guidelines.
OK - License (GPL)
OK - License field in spec matches
OK - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
OK - BuildRequires correct
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
See below - Package has correct buildroot
OK - Package is code or permissible content.
OK - Packages %doc files don't affect runtime.
OK - Package compiles and builds on at least one arch.
OK - Package has no duplicate files in %files.
OK - Package doesn't own any directories other packages own.
OK - Package owns all the directories it creates.
See below - No rpmlint output.
OK - final provides and requires are sane:
OK - Should build in mock.
OK - Should build on all supported archs
OK - Should function as described.
See below - Should have dist tag
See below - Should package latest version
0 outstanding bugs - check for outstanding bugs on package.
1. Buildroot should be the standard one.
2. rpmlint says:
E: xrestop zero-length /usr/share/doc/xrestop-0.2/NEWS
Drop the NEWS file? Also the INSTALL file is the generic autotools one, and
should also be dropped.
3. Should use the dist tag?
4. The latest version is 0.4 upstream.
I think you can then also drop the man patch as this is fixed upstream.
5. There's some odd # SUBDIRS= comments that should get removed...
Resetting flags and such per the new offical review guidelines:
Any news here?
As far as I can tell you've never commited to this package, do you still want to maintain it?
Items 1 and 5 are outstanding still... all the others have been fixed by other people over the years.
The buildroot does meet the guidelines, even though it's not a standard one.
The comments are not a blocker.
I guess I will go ahead and APPROVE this review, but it seems odd to have a package maintained by someone who has never once commited to it.