Am 18.04.2016 um 02:15 schrieb Ben Finney: > Markus Koschany <apo@debian.org> writes: > >> I had a look at your package and wanted to give you some feedback >> because of the effort you put into packaging this game. > > Thank you! Are you a prospective sponsor of this package? Yes, I would sponsor the package if we can resolve the remaining issues. >> The vim comments at the bottom are not allowed (syntax-wise) > > Those are in end-line comments (“# foo”). My understanding is that > end-line comments with that syntax are permitted in any Debian control > files. cme check dpkg made me aware of this and it probably refers to: https://www.debian.org/doc/debian-policy/ch-controlfields#s-controlsyntax "Lines starting with # without any preceding whitespace are comments lines that are only permitted in source package control files (debian/control). These comment lines are ignored, even between two continuation lines. They do not end logical lines." The file syntax of copyright format 1.0 files is the same as for other control files. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#file-syntax >> CC-BY-2.0 is not a DFSG-free license, if possible better use CC-BY-3.0 >> or CC-BY-4.0 > > Thanks. The package includes works I have derived from upstream works > licensed under CC By-2.0. > > My understanding of the problems with CC licenses version 2.0 is in the > potential for some licensors to set impractical restrictions on > attribution. That is not the case for any of these specific works, so I > think they are DFSG-free currently. > > To avoid such problems arising for the derived works, I will set the > license to CC By-4.0 in those derived works as distributed in Debian. CC-BY-4.0 is a good choice and would help to avoid any confusion. I agree with you that CC-BY-2.0 is debatable but I'd rather prefer not to open a can of worms here. On the following site are a few links of older discussion: https://wiki.debian.org/DFSGLicenses >> You have patched the upstream sources (12 patches). In general the >> patches look O.K but I wonder if they are all necessary. Did you >> forward them upstream? Why do you think Debian should diverge from >> upstream? > > Those patches turn the work into a useable stand-alone program for > Debian. Each one is submitted upstream, and I'm corresponding with the > upstream maintainer to get these changes incorporated. Fair enough. >> You split the game into three arch:all binary packages. I'm not >> totally convinced that this is really necessary for a game like >> python-adventure. Your current approach is not totally wrong either, >> perhaps a bit too perfectionist though. Are there strong reasons why >> you split the game into three parts? > > I would think rather that conforming to Debian policy would be the > default, and a divergence would need a strong reason. I'm not so sure about your last sentence since the Policy doesn't dictate this particular packaging scheme IMO but I'd stand corrected if you could point me to the relevant Policy part. Bas Wijnen has already voiced some of my concerns in his previous e-mail. In my opinion we should also take practical reasons into account and creating three arch:all packages for such a trivial game comes with a lot of overhead. For example adventure-common just ships the 50kb small advent.dat file. Sometimes I need to package annotations or libraries that can be equally small in seize but in those cases there is always a concrete package in need of those dependencies. Here there only could be a potential consumer in the future, which is also rather unlikely, but I can't imagine that the trade off between meta data and maintenance costs and saving 50 kb is really worth it. I recommend to merge advent.dat into colossal-cave-adventure and be done with it. I can live with the python3-adventure split off but as Bas already said I also find it unlikely that another program will ever make use of it. >> Why don't you join the Python or Games Team and maintain >> python-adventure within one of these teams? > > No particular reason. I am enjoying maintaining the code as it is. Ok. The keyword is maintaining. In general I don't find it important where people actually maintain software as long if they keep it updated and in good shape. Still I would encourage you to join a team because it often simplifies regular tasks like finding a sponsor. Could you remove those ^L form feed characters please? Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature