Bug#766441: RFA: scala-mode-el -- Emacs major mode for editing scala source code

[Sławomir Wójcik <valdaer@gmail.com>]

On 29.05.2020 05:22, Nicholas D Steeves wrote:
> Hi Sławomir,
>
> Sławomir Wójcik <valdaer@gmail.com> writes:
>
> > On 22.05.2020 05:14, Nicholas D Steeves wrote:
> >
> > I've merged my changes into new repo initialized by gbp import-dsc from
> > the old package, it's here:
> > https://salsa.debian.org/Valdaer/scala-mode-el. Documented all of it in
> > the new changelog entry.
> >
> > The newly built package is here:
> > https://mentors.debian.net/package/scala-mode-el
>
> Thank you for your work on this package; this one needs a fair bit of
> work before it will meet current standards.  Sorry, it's not ready to
> sponsor yet.
>
> I'm short on time for the next week, and am exhausted right now, but
> here's a very quick review.  Please read it as if I had written "please"
> before every point, and sorry it seems terse or vague.  I just wanted to
> send you the list of things to work on before I'll have time to review
> again--probably in about a week:
>
> Hint to save time: checkout the commit where you merged the upstream
> tag, then 'git checkout -b merged-new-upstream-source'.  If ever you
> need to rebase you can then rebase against that branch; if you need to
> rebase, this will help avoid the sticky mess of non-fastforwarding master
> branch that might not be a child of upstream.
>
> Leave the changelog in UNRELEASED state for now.

Ok

> Push upstream version tags.

Done

> 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?

>    * 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 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.

>    * 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:

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?

>    * always dedicate one line to each year[s] copyright_holder_name <email>
>    * "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 ;-)
>    * date ranges can be tricky.  I believe you see the value in combining
>    them, but it's also important to guard against false matches.  For a
>    small package like this comprehensive detail is expected.
>    Silversearcher-ag (or similar) may make it faster to check for (C), ©,
>    and Copyright.
> Control file issues:
>    * revert that section change; editors is correct, lintian's claim
>    notwithstanding.  Thank you for reading lintian output, btw.
>    * use debhelper-compat 13 (p.s. apt install -t buster-backports
>    lintian.  Lintian should have caught this)
>    * 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.
>    * drop emacs25

Done

>    * 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.

Added information about this in NEWS file and expanded long description.

>    * 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.

>    
> elpa-test:
>    * nice catch on the ert_eval! :-)
>
> I'll review the changelog in more depth in the next cycle.  eg:
>
> changelog:
>    * "Removed old and no longer necessary files" <- removed what, and
>    what was it that made it no longer necessary?  Was it part of a larger
>    objective?  Was it an upstream change, a change in Debian tooling, a
>    change you made, etc.

Done

> If you're in a time zone where no one seems to every be active in
> #debian-emacs, try #debian-mentors, otherwise someone else on this list
> may have the time to point you in the right direction--assuming I'm too
> busy.  'hope this list is just the right length, without being too long
> or two hard, and that you find the learning process rewarding.  The good
> news is that there's a reason for most everything and there should be
> high-quality documentation somewhere, the bad news (for people who don't
> like to read) is that it's a lot to read and some things can be tricky
> to find until one figures out the key words.  Feel free to take as many
> breaks and as much time as you need; that said, before 2021 would be
> nice--to unblock my ITP for smartparens ;-)
>
>
> Have fun!
> Nicholas

Thanks for the review, fixed most of your comments, asked questions 
above for others please look at these and clarify when you will have time.

I'm actually active mostly somewhat between Europe and US timezones, I 
live in Poland but I often work with US based companies. Recently I'm 
busy with some personal matters also so I don't have time to go online 
on IRC probably I will show up there in future(unless you prefer to 
arrange some meeting there at some specific date/time we could agree on)

Cheers
Sławomir