[Debian-olpc-devel] Sponsorship / review request (multiple activities)

[Jonas Smedegaard]

On Thu, Jul 22, 2010 at 01:34:02PM -0400, Luke Faraone wrote:
>A group of new developers from SEETA have been packaging new Sugar 
>activities, as you've all seen from my reviews on the mailing list. A 
>few of them are, in my opinion, ready for an upload. IANADD, so my 
>opinion is the only thing I can provide :)

So I now finally - after quite a few friendly poking from Luke here at 
Debconf which we both attend - found/took some time to look at the 
panding packages.

Overall they look great!  Probably a lot better than my own early 
releases of Sugar packages :-)

What follows is therefore mostly small improvements and nitpicking...:


I tend to add a comment at the top of debian/watch explaining its 
purpose.  Reason for this is that personally when I started packaging I 
failed to guess that "watch" was explained in "man uscan".  Have a look 
at just about any package I've ever packaged for an example of what I 
consider a useful hint in that file. :-)

In debian/copyright I prefer to always put license sections at the 
bottom.  This is in my interpretation mandatory when reusing a License, 
but even when only used once I find nicer to be able to skim through 
files sections separately from License sections.  I tend to sort the 
License sections with the most popular (in that specific package) 
license first (i.e. at the top of the bottom, if you know what I mean).

In debian/changelog I like to clearly separate bug-closures from other 
parts, and have found that writing it as a separate sentence instead of 
inside paranthesis "()" eases reading, as does adding a newline (but 
keeping it in same section, so not adding an asterisk "*").  Also, I 
like to make it clear that it is bugreports by using the optional "bug" 
in front of the "#" (if closing multiple bugs I would only do it for the 
first, as in "Closes: bug#123456, #654321"). So more specifically, I 
would write the initial changelog entry like this:

    * Initial release.
      Closes: bug#123456.

Make sure to encode licenses in debian/copyright with a single dot on 
each otherwise empty line.

Also, make sure to include the licensing statement verbatim (i.e. word 
by word).  Example: When debian/rules states the long common section 
starting with "This program is free software; you can..." then just 
writing "The Debian packaging information is under the GPL, version 2 or 
later." in debian/copyright is not enough.

Order of Files sections in debian/copyright is important: To both 
improve readability and avoid accidentally shadowing some sections by 
others, I strongly recommend the following order:

   1) default - i.e. "*" or the Files: lines left out completely
   2) subdir match using wildcard
   3) file match
   4) explicit path match
   5) ./debian/* match
   6) debian subdir match - e.g. ./debian/patches/*

While at it, I prefer to have licenses reformatted to be wrapped at 72 
chars.

Copyright holders need not be comma-separated - so I suggest stripping 
the few stray trailing commas.

Copyright holders also need not include a copyright sign "©" (as I 
understand it, US laws require _either_ the explicit word "copyright" 
_or_ the copyright sign, so for simplicity I suggest consistently 
dropping it.

I recommend to use the CDBS snippet upstream-tarball.mk instead of local 
get-orig-source routines.  Yes, it supports dfsg-repackaging of upstream 
tarballs too.  No, it does not support rolling unofficial tarballs from 
e.g. Git snapshots - please convince upstream to release tarballs in 
such cases!

There should be no need to remove COPYING files from binary packages: 
the CDBS snippet python-sugar.mk replaces those with a symlink if truly 
fully identical to the Debian-shipped file.

Make sure to add a debian/README.source file - and to refer to that wiki 
page Ankar wrote recently: http://wiki.debian.org/Sugar/README

Wrap long descriptions in debian/control (and debian/control.in) as 72 
chars.  No more and at least possible less than that.

Is olpcgames really only used in the Physics activity?  If not it should 
be packaged separatedly and reused instead.


That was some comments.  I guess I'll let this sink in, and have another 
closer look later... :-)


Regards,

  - Jonas

-- 
   * Jonas Smedegaard - idealist & Internet-arkitekt
   * Tlf.: +45 40843136  Website: http://dr.jones.dk/

   [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20100802/59d2e1cc/attachment.pgp>