[3dprinter-general] A Sponsor for Printrun

[Bas Wijnen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, and welcome!

I haven't looked at the package yet, but here is some response to the questions
you raised in the ITP:

> The messy debian/changelog file and the "re-versioning":

debian/changelog is about things that actually appeared in Debian, so the
non-released versions do not belong there.  At least that's my understanding,
others may disagree.  There's definitely a grey area if it was originally
released in a less public place, for example (in other words, if people may
have the old versions installed on their system).

UNRELEASED should only be used for the top entry, while it is not yet released.
It should not appear anywhere else.

Giving credit to the work you based your packaging on is good, but
debian/changelog is not the place to do it (unless the work was in Debian); it
should go in debian/copyright.

> Richard Ulrich started the packaging using a versioning scheme of the form
> 1.2.3, which had nothing to do with the upstream versioning scheme, which is
> in the form of YYYYMMDD. To be coherent with upstream and ensure a potential
> future smooth transition to a scheme of the form 1.2.3, versioning scheme has
> been restarted to 1:0~YYYYMMDD.

A version of the form YYYMMDD sorts properly, so you can simply use it without
"0~".  It is higher than the last released version (that people may have
installed; if in doubt, only versions in Debian count), so no need to add an
epoch either.

> Pedantic mode of Lintian warns against the lack of a proper upstream
> changelog:

Lintian complains about bugs in the packaging, and as a maintainer you should
fix those.  But it also complains about upstream bugs.  As a maintainer, you
are encouraged to convince upstream to fix those, but you cannot fix them in
the packaging.

One reason that an upstream changelog is important is that several licenses
(most notably the GPL) require authors to document their changes, and the
changelog satisfies this requirement.  In a git repository, the output of "git
log" probably does as well, though.  You may want to ask debian-legal if you
need to include the output of that to satisfy the license.  Check if what I say
here is correct before you do that though; it's just what I remember.

My guess is that in this case upstream will not care about adding a changelog,
and I don't blame them.  So then there are three things that can be done:

1. Keep the warning and hope that upstream changes their mind at some point.
   Optionally talk to upstream to try to convince them of the benefits of
   fixing this.  This is mostly an option if you disagree with upstream, which
   in this case I don't think I do (but if the output of git log needs to
   accompany a distribution, that would of course also be true for their own
   release).
2. Report a bug to Lintian that this should not trigger a warning.  That is an
   option if you consider it a false positive, and many other packages are
   likely suffering from it as well.  That seems reasonable in this case.
3. Add a lintian override to your package.  THIS IS ALMOST ALWAYS WRONG!  Use
   this if it's a false positive (so Lintian is wrong) AND your package is a
   very special case.  In other words, the warning is almost always correct,
   but in your package for some reason it isn't.  Instead of adding an
   exception to Lintian which is used by almost no packages, you should silence
   the warning.  If something is a real bug, but the maintainer considers it
   unimportant, an override is inappropriate; that would just hide the bug
   (however small it is) and in our social contract we promise not to do that.

So your options here are 1 and 2.  I would go for 2, but on the other hand if
you ask for it to be pedantic, I suppose you should expect false positives; the
Linian maintainers may also have an opinion on this, which is obviously more
important than mine.  And if the legal case I made above means it is a real
bug, you should go for 1 (and add the output into your package until upstream
fixes it).

> Pedantic mode of Lintian warns against unsigned upstream tarballs.

Same thing, but for this I would go for option 1.  Signed releases have
real benefits.

> Executable's (binaries? is there any difference?) names:

Strictly speaking, binaries are compiled code, which includes many executables
and libraries, but not scripts.  Executables is everything you can run directly
from the commandline, so that doesn't include libraries.  Many people confuse
them however; large Python executables are often called binaries for example.

To make it even more confusing, Debian has "source" and "binary" packages;
binary packages are what gets installed; it doesn't mean there's even a single
binary in them.

> I have kept it this way to be coherent with upstream, but I feel it would be
> better if these executables were renamed to something like the following for
> coherence between the package name and its available commands:

Staying in sync with upstream is more important.  Unless there is a naming
conflict with another package, you should use the executable names they use.
It is worth convincing upstream to change their names, but if they don't then
Debian prefers to be in sync with other distributions and upstream.

> And one last question, if I were to modify the package after this revision,
> should I delete the previous upload to debian.mentors.net and upload the new
> version with the same name? or should I upload a new version named *-2?

I think you should just upload another package with the same version number;
the uploads to mentors are just work in progress, so the changelog should not
increment for every iteration.

Thanks,
Bas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW0MStAAoJEJzRfVgHwHE60/AP+QF9D1SGY5ufYOJSXYBzXSjU
AGRt93EmRfOG6MdTMuWc//JH4lWDED73i8esq8a7LlfdO/mzORJba+2PakD+ej8W
SFIvqXgtu6DSQWyHVAAw7x5YkLKI1IxcWUdJVaipDzf2r2WEIB6QcDYgkgJszEkj
EDNZdUpchFmJkvupKR2D/yv7VkmxbN4EE9G/UZPCs8b0T1w6FQgDScgLmoISCalc
8FbjRvDdQEjGjWbTo57O36rqo2sM3N0B8ExmS2rABdoN/81eXNIthOwrhkd1DdIl
mUiNRvW+8o1k4tTaLRiHGxybKW7JYMXXcTuc3ElM8h2cm2KQnGPfRwYAtW0NNol2
L9dD/pJKIiTamYdkPN9OrkJp7Nyh+p+HLJQRxrQNW2C56f8NSRY1Nr2o4jGUTi5t
Lp/m2qdZ2NkLQmIgMQpCG8l4D63dZy/H0awonnhFhTDgRqmffx6BPoTYHlhmKHc9
nrBTuDaUb9HvZ+HEtrfVOLGlWU/ij6EdYDSDPfXF0wcBUlD3FflNS+cp6b0vi8KF
aUYnup5SL9BMTDo6po7EeA/okUqUjHrbGw6lUo8PsMIb8Gdrv8qjz0jXglauuQyI
obvC95wMX7MkNlKCuabxFxwdX8e1HCJzZsUKj6zL17KWe/XExKOYCOqcNBfGi4Q9
Mjr3jgPqbWgRlD3zOIb7
=Qdbf
-----END PGP SIGNATURE-----