Hi Sławomir,
Thank you for the updates! I've elided the resolved issues in this
reply.
Sławomir Wójcik <valdaer@gmail.com> writes:
> On 29.05.2020 05:22, Nicholas D Steeves wrote:
>> Sławomir Wójcik <valdaer@gmail.com> writes:
>>> On 22.05.2020 05:14, Nicholas D Steeves wrote:
[snip]
>> Leave the changelog in UNRELEASED state for now.
> Ok
But then you committed ce7b824 knowing the package wasn't ready for
release...
[snip]
>
>> Copyright file issues:
>> * 2 files stanzas are missing
>
> which two? I've browsed all files and I'm not sure. Could you paste some
> links to locations in the repo?
>
You can find these with:
ag copyright --ignore debian
ag © --ignore debian # compose that symbol with 'compose_key-o c'
# or just copy & paste
ag '\(c\)' --ignore debian
>> * 2 people are missing
>
> I've added Merlin Göttlinger as the author of
> scala-mode-prettify-symbols.el file and Ana Beatriz Guerrero Lopez in
> debian files dopyright section.
>
I appreciate you took the time for this. That said, Ana Beatriz
Guerreroo Lopez doesn't need to be (most would say shouldn't be) in the
copyright file, because ~5 lines of small changes (plus two
dch-generated lines) doesn't meet the minimum standards for
copyrightability. This becomes significant when there are many
contributors who have make small or trivial changes to debian/*, because
were a license change to be required sometime in the future, all
copyright holders would need to affirm the change.
> I could add Sam Halliday(original author of https://ensime.github.io/ ,
> more info below) who contributed some substantial part of scala-mode,
> however he abandoned the project.
>
> What's the policy here? Should we include him in copyright? For example
> in elpy package only the original author(Jorgen Schaefer
> <contact@jorgenschaefer.de>) is listed in the copyright entry and the
> person which took over the project(galaunay
> <gaby.launay@protonmail.com>) is only listed as upstream contact and not
> in the copyright section.
>
In Debian our obligation is to 1) accurately reflect upstream copyright
declarations 2) contact upstream when something is not clear, or when
there is a DFSG issue such as bundling software with incompatible
licenses in the same repo or orig.tarball. In Elpy's case Launay is the
current maintainer, but he not asserting his copyright rights and/or has
attributed copyright of his work to Schaefer.
If you ran the commands suggested above you'll have seen that Sam
Halliday is still a copyright holder. Knowing scala-mode's history,
this makes it seem like Heikki Vesalainen derived his work from
Halliday's. As discussed previously I don't think it's fair or just to
cut people from history because they stopped maintaining a project, but
the absence of Halliday's copyright claim is an upstream issue. Were I
to contact upstream, phrasing it as a request for clarification would be
less confrontational than something along the lines of "hey, you've
omitted someone's copyright", and I'd go with the less confrontational
approach. By the way, you don't have to contact upstream if you don't
want to, because this issue doesn't strictly block Debian work.
>> * at least 1 license is missing
>
> I've added Scala EPFL license which I missed that is still used in
> Makefile(which I believe is invoked by debhelper, although I'm not sure
> it's needed for dh_elpa) but one question here:
License names should be one word (no spaces).
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification
> What would be the policy for files that Debian package doesn't use not
> only in the debian binary package but even in the build process like for
> example Cask file which would have separate license? In that case this
> license should also be incorporated in the copyright file?
>
If it's in the orig.tarball and thus the source package it needs to be
documented; this is written in Policy. If the license is not DFSG free
then the file[s] must be stripped from the orig.tarball, even if they're
not used during the build and even if they don't appear in a binary package.
>> * "updated license and author" is too vague, and isn't entirely
>> accurate (see above). Also, why did the licenses and authors change?
>> Documenting these facts is part of writing a good changelog entry
>> ;-)
This isn't present in ce7b824, please fix it.
>> * Standards-Version needs to be updated. See Debian Policy and its
>> upgrading checklist. Start at the version from the last upload and
>> work your way through from there. <- Please defer this until the
>> beginning of our next review cycle unless you run out of things to
>> do.
This is the second most important changelog item, and the most important
from a Policy perspective, so it should go on its own line. It should
say something like this:
* Declare Standards-Version 4.5.0
or
* Assert compliance with Policy 4.5.0.
etc
If no changes are required add "(no changes required)" to that line,
otherwise list all the changes you made while completing the upgrade
checklist. P.S. I believe I CCed you a conversation with dkrauser with
a more in-depth explanation of this.
>> * expand the long description by a line or two (did this version lose
>> the ability to send sexps to a scala process? If so, document it in
>> NEWS) Is it just a boring mode that does very little or does it have
>> any outstanding and/or cool features?
>> - NOTE: if this this new upstream source has less functionality than
>> the previous one it might be worth documenting the changes. If it
>> has a significantly different keymap or workflow, or breaks existing
>> users' configs then do you think users would appreciate
>> notification? If so, read up on the NEWS file (found in
>> debian/NEWS) and how to use it.
>
> Yeah it's probably because the new scala-mode(once called scala-mode2 as
> in https://github.com/hvesalai/emacs-scala-mode/tree/v0.22 which I think
> was a fork of original scala-mode however I'm not sure I haven't been
> programming in Scala back then, and even if it was in IntelliJ) was
> meant to work in synergy with ensime(https://ensime.github.io/) which is
> now abandoned and has been replaced by scala
> Metals(https://scalameta.org/metals/) which is used by emacs lsp-mode/eglot.
>
Despite not programming in Scala "back then" it sounds like you have a
good grasp of the Scala-related Emacs history, and it makes me happy
someone with this knowledge will be maintaining the package!
> Added information about this in NEWS file and expanded long description.
>
The first paragraph of NEWS needs to mention that the Debian package
uses a new upstream source/project. The changelog also needs to mention
this, because it's not just a new version from the same source, because
this is also the most important fact to document in the changelog from
an end-user perspective.
Also, please take care that parentheses have a leading space eg:
"this(example) continues" vs "this (example) continues". The second
example is correct.
Other than that, NEWS good to me, and I believe users will appreciate
the hints you've provided in the second paragraph.
>> * missing dummy transitional package, Breaks, and Provides; at present
>> an upgrade path has not been provided.
>
> Done, don't know why I forgot that after our discussion about
> source/binary package names.
>
No worries, the requirements are a lot of information to process, and
boring things are especially hard to remember ;-) The dummy package is a
step in the right direction, but Breaks, Replaces, and Provides are
still missing from control. Do you need a hint?
Cheers,
Nicholas
Attachment:
signature.asc
Description: PGP signature