Re: looking for sponsor for my package "jscribble"
On 2011-08-02 03:42, Martin Ueding wrote:
> Dear Niels,
>
Hi,
>
>> I have reviewed your package and there some issues with it. It may
>> appear as if I am tearing your package completely apart, but it is
>> intended as constructive criticism to improve your package.
>
> Thank you very much for the detailed review!
>
You are welcome :)
>
>> The package does not close an ITP (Intend To Package) bug, the new
>> maintainer's guide explain how this can be done[1]. This serves a
>> number of purposes, such as avoiding duplicate work.
>
> I tried to file a bug today, but it reportbug told me that it was unable
> to connect to Debian BTS. I tried with 5.1.1 and 4.12.6ubuntu1.
>
> Then I tried to send a bug report via email:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636295
>
My guess is that it tried to query the BTS for similar bugs against the
pseudo-package wnpp and time-outed. http://bugs.debian.org/wnpp as a
huge list of bugs and is extremely slow - Personally I prefer using
http://wnpp.debian.net instead, though it may be "slightly" out of date
as it uses a cache.
>
>> I wonder if the synopsis could be extended a bit to give a clear idea of
>> what the application does. Personally, "Infinite Notepad" made me think
>> it was a "Windows Notepad" clone or something similar.
>
> You are right, I changed it to "graphical notepad for use with a pen
> tablet".
>
:)
I forgot to look at the long description last time, Sorry.
I am not too sure on the `...` quoting-style. I think "..." is better,
but I could be wrong, so I am hoping to get a second opinion from the
list. :) I suppose it is related to the use of 10" as ""10 inch""?
Also (re-spaced due to my Mail client):
"""
Taking notes on paper allow you to draw and write whatever you want.
Some people are fast enough in LaTeX to set complicated formulas while
in a lecture. Some prefer to draw these by hand but do not like
carrying lots of paper with me.
"""
I think the "me" should be "them", but I am also thinking it might be
better to re-word the entire paragraph.
"""
Another focus was set to avoid any mouse navigation. All you can do with
your mouse (or pen) is draw, therefore you cannot click anything
accidentially. Navigation is done with the keyboard.
"""
Also I think this paragraph could a little rephrase. I think it is
better to "sell" the feature rather than the design choice. Maybe it is
enough to just remove the first sentence...
A good read here would be [DR-6.2]; if you have problems with this, feel
free to (ab)use <debian-l10n-english@lists.debian.org> for reviews. :)
[DR-6.2]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-desc-basics
See both 6.2.1 and 6.2.3
>
>> The source package has a warning about the Standards-Versions being out
>> of date. I can recommend using the upgrade check list (in the
>> debian-policy package or at [2]). Ignore the "Unreleased" note under
>> 3.9.2, the maintainers forgot to remove it in the last upload.
>
> Are the package supposed to be build on unstable? I currently build it
> on Ubuntu 11.04 for which the version is the current standard.
>
When uploading to Debian unstable, yes. You do not have to install
Debian to do this though; a sid chroot will suffice for the common cases
(pbuilder/cowbuilder can be of use here).
Plus Ubuntu has modified some of the build tools (e.g. debhelper), so
there are some slight differences in the result.
>
>> If you did not know it, lintian can be run on .dsc-, .(u)deb- and
>> .changes-files. When run on .changes-files it will process all files
>> listed in it. Generally lintian gives the best results if all the
>> packages are processed together.
>
> The only lint it finds is that there is no upstream changelog.
>
That is a pedantic tag as I recall; that's okay provided that there is
no upstream changelog - that being said, an upstream changelog is good
to have for reference.
On a slightly related note, this is one of the cases where Debian and
Ubuntu have a difference. debhelper in Debian will try to auto-install
the upstream changelog (if any), where-as in Ubuntu they patched-out
that behaviour.
Ubuntu have been known to patch Lintian to better reflect their build
setup, but with Lintian 2.5.2 (not yet in sid[L]) this is no longer
needed and you can (on a non-Debian machine) use "lintian --vendor
debian" to get the output Lintian would have made on a Debian system.
That being said, Lintian can very quickly get out of date, so it is
generally a good idea to use the newest version from sid.
btw, for a non-native package I would expect it to nag about a missing
watch file (with --display-info).
[L] I believe Ubuntu carries a 2.5.2 pre-release in the (expected to
become) 11.10 release.
>
>> What about future motivation?
>> - Would you be willing to support jscribble in Debian for 2 years?
>> (This is the average length of a stable release)
>
> Since I plan on using this software for the next years, I would be able
> to support it.
>
That sounds good. :)
>
>> - Do you see yourself working on other parts of or packages in Debian?
>> (i.e.: would you be interested in joining the Debian Java Team?)
>
> I will have to see how much time I have once university starts.
>
Certainly; this is not a requirement for getting a package into Debian,
but we can use all the help we can get. :)
Should you be interested in helping Debian, there was a talk/lecture
about how to contribute to Debian[1]. I did not watch the entire video
myself, they suggest a lot of non-packaging things you can work with.
Particularly some of them may be easier to fit into your schedule.
Since you are coding in Java, you may find [2] interesting as well.
[1] http://penta.debconf.org/dc11_schedule/events/805.en.html
[2] http://penta.debconf.org/dc11_schedule/events/718.en.html
>
>> On some platforms, default-jdk has the version "2:1.5", which would give
>> you a 1.5 Java. You may want to consider using
>> openjdk-6-{jdk,jre} | sun-java6-{jdk,jre} instead.
>
> Somebody told me that using default-jre was preferred since it does not
> tell people which jre to use. So I would use openjdk in this case to
> prevent this quirk of messing with the package?
>
Generally you want "default-jre | $relevant_alternatives" to make the
package able to use any JRE in Debian. It was your versioning that made
me use the openjdk-6 | sun-java6 example.
For building it is probably best just to use one package instead of
the alternatives I originally suggested. If you need swing or/and Java
6, I would go with openjdk-6-jdk in build-depends.
Anyhow, the (>= 1.6) part is redundant, since it is always "satisfied"
(all our tools consider 1:1.5 greater than 1.6)[PM-V].
[PM-V]
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
>
>> License: None of the files in the upstream part (that is anything not in
>> the debian directory) appears to have any licenses, nor does the package
>> carry a license. Since you are (also) the upstream maintainer, this
>> should be trivial to fix.
>
> I included the header in all the source files and put a full text into
> the directory.
>
Sounds Perfect :)
>
>> d/watch: Missing - while you are your own upstream, it is still a good
>> custom to have a watch file. Particularly, if you later step down from
>> either position, we will have tools to detect if the package is out of date.
>
> This I did not fix yet, I will look into it in the future.
>
That is fine. :)
>
>> tests: There are tests in the package, but they do appear to be run.
>> Can they be run during the build? debhelper should be able to pick it
>> up if the makefile has a "test" or a "check" target. (Remember to
>> update Build-Depends accordingly).
>
> I created a target that exercises all unit tests to the makefile. Junit
> is now also part of the dependencies.
>
Thanks. :) There has recently been an interest in getting more
build-time test suites and getting more of them run during the build.
They tend to help us find regressions as well when experimenting with
"big" changes.
>
>> native: The package has been created as a native package, but this
>> package is not a "By Debian, For Debian" package. See [4] for more
>> information.
>
> Okay, I changed it to non-native.
>
Thanks.
>
>> d/install: You should probably use d/manpages for the manpage (see
>> man dh_installmanpages).
>
> This is way better than my workaround with the makefile. Thanks!
>
You are welcome, :) man 7 debhelper also have a list with most of the
debhelper(-like) tools that you may find useful.
btw, I meant dh_installman and not dh_installmanpages (misremembered the
name, the latter happens to be deprecated)
>
> [...]
>
>> d/control [pedantic]: On a more pedantic note, why the Build-Depends on
>> debhelper (>= 7.0.50~). 7.0.50~ is only needed if use override targets
>> (which you do not), so a >= 7 would work just fine. Alternatively
>> debhelper 8 is out, so you can (if you like) bump the compat level (and
>> the Build-Depends) to 8.
>
> Ubuntu even ships 8.1.2. Is there any advantage of doing so? I guess it
> would be easier to backport if the version is as low as possible.
>
For Debian, debhelper 8 is available in squeeze (stable) and in
lenny-backports (oldstable-backports). Since you will be the maintainer
of the package, it is your decision.
Personally I do not care either way; as long as you have a reason for
your choice. I was merely wondering why you chose "7.0.50~" when you
were not using override targets.
>
>> I hope you find the feedback useful. :)
>
> Very much so!
>
>
> I uploaded version 1.0.1-1 of the package now.
>
I noticed there is an empty field (Source) in d/copyright; is that
intentional?
d/docs can be removed (as it is now an empty file). :)
>
> Regards,
>
> Martin
>
> --
> [...]
~Niels
Reply to: