[Bug 598058] Review Request: maven-docck-plugin - Maven Documentation Checker Plugin

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=598058

--- Comment #9 from huwang <huwang at redhat.com> 2010-06-03 04:35:29 EDT ---
(In reply to comment #8)
> NEEDSWORK: rpmlint must be run on every package. The output should be posted in
> the review.
> maven-docck-plugin.src: W: invalid-url Source0: maven-docck-plugin-1.0.tar.gz
> maven-docck-plugin.noarch: W: self-obsoletion maven2-plugin-docck <= 0:2.0.8
> obsoletes maven2-plugin-docck = 1.0-1.fc13
> maven-docck-plugin.noarch: W: no-documentation
> maven-docck-plugin.noarch: W: non-conffile-in-etc
> /etc/maven/fragments/maven-docck-plugin
> 3 packages and 0 specfiles checked; 0 errors, 4 warnings.
> 
> Everything except self-obsoletion is false-positive. You need to fix
> that self-obsoletion (by adding epoch 1 to provides) though.
> 
> OK: The package must be named according to the Package Naming Guidelines .
> OK: The spec file name must match the base package %{name}, in the format
> %{name}.spec unless your package has an exemption.  .
> OK: The package must meet the Packaging Guidelines .
> OK: The package must be licensed with a Fedora approved license and meet the
> Licensing Guidelines .
> OK: The License field in the package spec file must match the actual license. 
> OK: If (and only if) the source package includes the text of the license(s) in
> its own file, then that file, containing the text of the license(s) for the
> package must be included in %doc.
> OK: The spec file must be written in American English. 
> OK: The spec file for the package MUST be legible. 
> OK: The sources used to build the package must match the upstream source, as
> provided in the spec URL. Reviewers should use md5sum for this task. If no
> upstream URL can be specified for this package, please see the Source URL
> Guidelines for how to deal with this.
> OK: The package MUST successfully compile and build into binary rpms on at
> least one primary architecture. 
> OK: If the package does not successfully compile, build or work on an
> architecture, then those architectures should be listed in the spec in
> ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in
> bugzilla, describing the reason that the package does not compile/build/work on
> that architecture. The bug number MUST be placed in a comment, next to the
> corresponding ExcludeArch line. 
> OK: All build dependencies must be listed in BuildRequires, except for any that
> are listed in the exceptions section of the Packaging Guidelines ; inclusion of
> those as BuildRequires is optional. Apply common sense.
> OK: The spec file MUST handle locales properly. This is done by using the
> %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
> OK: A package must own all directories that it creates. If it does not create a
> directory that it uses, then it should require a package which does create that
> directory. 
> OK: A Fedora package must not list a file more than once in the spec file's
> %files listings. 
> OK: Permissions on files must be set properly. Executables should be set with
> executable permissions, for example. Every %files section must include a
> %defattr(...) line. 
> OK: Each package must consistently use macros. 
> OK: The package must contain code, or permissable content. 
> OK: Large documentation files must go in a -doc subpackage. (The definition of
> large is left up to the packager's best judgement, but is not restricted to
> size. Large can refer to either size or quantity). 
> OK: If a package includes something as %doc, it must not affect the runtime of
> the application. To summarize: If it is in %doc, the program must run properly
> if it is not present. 
> OK: Packages must not own files or directories already owned by other packages.
> The rule of thumb here is that the first package to be installed should own the
> files or directories that other packages may rely upon. This means, for
> example, that no package in Fedora should ever share ownership with any of the
> files or directories owned by the filesystem or man package. If you feel that
> you have a good reason to own a file or directory that another package owns,
> then please present that at package review time. 
> OK: All filenames in rpm packages must be valid UTF-8. 
> 
> Other notes:
> You are using gzip compression to create tarball from SVN. Using xz
> compression creates smaller archives (saving space on dist machines)
> and is fully supported. You can create xz archive by doing:
> tar acf maven-docck-plugin-1.0.tar.xz maven-docck-plugin-1.0/
> (don't forget to change Source0 URL afterwards)
> 
> Another (tiny) thing to be careful about for future is to try to be
> consistent in every way possible. For example you are using 0755 in
> one place and few lines down you use 755. Pick one style and stick
> with it. 
> 
> A small tip. It's also possible to install file and create all the
> directories in one step. For example:
> 
> install -d -m 0755 %{buildroot}%{_javadir}
> install -m 644 target/%{name}-%{version}.jar  
> %{buildroot}%{_javadir}/%{name}-%{version}.jar
> 
> could be rewritten as (with preserving file timestamps):
> 
> install -Dpm 644 target/%{name}-%{version}.jar  
> %{buildroot}%{_javadir}/%{name}-%{version}.jar
> 
> 
> So summarized:
>  * self-obsoletes
>  * compression
>  * consistency
> 
> At least first two points are necessary for approval, but I would
> suggest making spec file as consistent as possible while you are
> editing it.    

Fixed all. Please review again, thanks.

Spec URL:
http://huwang.fedorapeople.org/packages/maven-docck-plugin/maven-docck-plugin.spec
SRPM URL:
http://huwang.fedorapeople.org/packages/maven-docck-plugin/maven-docck-plugin-1.0-2.src.rpm

scratch built in koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2226745

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.