Review of gnome-gmail
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2010-09-25 15:28, David Steele wrote:
> Dear mentors,
> I am looking for a sponsor for my package "gnome-gmail".
>
> * Package name : gnome-gmail
> Version : 1.6-3
> Upstream Author : David Steele <daves@users.sourceforge.net>
> * URL : http://gnome-gmail.sourceforge.net/
> * License : GPL
> Section : gnome
> Language : Python
>
> It builds these binary packages:
> gnome-gmail - Add Gmail support to GNOME
>
> The package appears to be lintian clean.
>
> The upload would fix these bugs: 597903
>
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/g/gnome-gmail/
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/g/gnome-gmail/gnome-gmail_1.6-3.dsc
>
> Gnome Gmail adds support for the Gmail web client as a GNOME Preferred
> Application for email. Once selected, mailto links, Nautilus "Send
> File" commands, Open Office "Send Document" commands, etc, will cause
> an appropriate Gmail window to open in your default browser.
>
> You can read more about Gnome Gmail from the following Press coverage:
>
> Lifehacker -
> http://lifehacker.com/5493654/gnome-gmail-tightly-integrates-gmail-into-linux-desktops
> Linux Magazine Online - http://www.linux-magazine.com/content/view/full/42375
> Sourceforge Blog - http://sourceforge.net/blog/gnome-gmail-made-simple/
>
> Thanks for your assistance
>
>
Hi
(Sorry for the double mail - I forgot to send it to the mentor list as
well so others could see it had been answered)
Thanks for your interest in Debian. It looks like you have not received
any feedback on nor found a sponsor for your package yet. I have spent
some time reviewing your package and got a few comments for you, which I
hope you find useful.
Please note that I am not a Debian Developer (DD), so I cannot sponsor
your package even if you address all my comments/remarks. Also neither
python nor GNOME is my strong suit, so there are possibly some
python/GNOME specific things that I have missed in my review.
On a related note have you considered contacting/joining the Debian
GNOME or the Debian Python Apps team? These teams may be a better source
for help with your package and possibly also sponsors for your package.
Also you may want to read [1] if you have not already done so; there are
talks about how to improve the current RFS template and what some
mentors look for/would like to see in an RFS.
Anyhow; my review:
d/watch:
- Contains a lot of unused comments (left overs from dh_make)
d/rules:
- lots of unused comments (looks like left overs from dh_make)
- Consider using either dh $@ (a.k.a. the dh7 method or "tiny rules")
or cdbs. These tools can handle your entire build without any
override targets/modification to their default setup/run.
This would also remove a warning during the build [2].
- Even if you do not use dh7 or cdbs you should clean up your
d/rules files. As an example, there is nothing to do in the
binary-arch target.
Note: if you are joining a team, the team may have a helper tool
preference or a build style. In that case you probably want to stick
with the build styles preferred by the team.
d/control:
- ${shlibs:Depends} does not make sense for arch: all packages.
It finds "arch dependent" dependencies for native shared libraries.
- The Description (and possibly the Synopsis) needs improvement.
It might be a help to have a look at [3].
d/changelog:
- You have multiple revisions in your changelog, but this package has
not been released into Debian. Consider merging it into a single
entry[4].
Note there is no reason to repeat the "closes" for the
same bug (see man dpkg-buildpackage/dpkg-genchanges about the "-v"
flag for more information). Though if you need the package built
with the -v flag be sure to mention this in your RFS, so that your
sponsor is aware of it.
d/copyright:
- Looks like a mix of "freestyle" and the DEP-5 machine readable
format.
Either of those formats are acceptable, but the mix appears a bit
"weird" for me. I would recommend you choose either of the formats
and stick to it.
- You have claimed copyright for the year 2009, but there is no
mention of copyright in the upstream files except for
gnomemail.glade, which claims copyright for the year 2010 (about 200
lines into the file).
I am not sure if that single copyright mention in gnomemail.glade is
enough for the FTP-masters. Optimally you would write your copyright
statement plus the "license header" in all your source files.
- There is no explicit mention of allowing the GPLv2 or later in your
upstream pacakge as far as I can tell. COPYING only contains GPLv2
and none of the source file seems to carry an explicit license.
Note: The "How to apply GPL v2 to your program" example in COPYING
is not a permission to use your program under GPL v2 or later.
You have a "debian/debian/" dir in your source package. I skipped all
files in that dir, because I assumed their inclusion to be a mistake.
Lintian also has a few coments about your (binary) package:
$ lintian -EvI --pedantic ../gnome-gmail_1.6-3_i386.changes
[...]
N: Processing binary package gnome-gmail (version 1.6-3) ...
I: gnome-gmail: extended-description-is-probably-too-short
P: gnome-gmail: no-upstream-changelog
W: gnome-gmail: package-installs-into-etc-gconf-schemas
etc/gconf/schemas/gnome-gmail.schemas
The I tag I already mentioned in my comments about your d/control; it is
usaully far from a requirement to fix the P tag - though you may still
receive a comment on you (as an upstream) not maintaining an upstream
changelog.
Finally there is the warning (the W tag) which you ought to fix. If you
do not know what the tag means you can use:
$ lintian-info -t package-installs-into-etc-gconf-schemas
and lintian will explain it to you. (lintian also has an argument which
makes it print the explaination by default, so you do not have to use
lintian-info afterwards).
Note, I run lintian with more options than the default setting, since I
tend to find the extra tags helpful. While you are not required to
include all the tags like I do, most sponsors expect you to fix all E
and W tags (and a lot also expect most of the I tags to be fixed) except
when their happen to be "false-positives".
If you have any questions, please do not hesitate to write back,
~Niels
[1] http://lists.debian.org/debian-mentors/2010/10/msg00005.html
[2] dh_install: You asked that all arch in(dep) packages be built, but
there are none of that type.
[3]
http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-debian-control
Particularly section 6.2.1 - 6.2.3 (inclusive)
[4] I know that some sponsors prefer you always increment the debian
revision between their
feedback. Personally I would keep only a single revision until I got a
sponsor that preferred
it that way; however, if you prefer this method, then by all means stick
to it!
Ref: http://people.debian.org/~codehelp/#sponsor (item 2)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREIAAYFAkyqV2wACgkQVCqoiq1YlqwcGwCfXVn4I5JelWPjaRVs7/2YVmQ1
bNQAn3/D27mJnvdTeTdbcYjQDHPREPg1
=2gRH
-----END PGP SIGNATURE-----
Reply to: