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

[Nicholas D Steeves]

Hi Sławomir,

Thank you for the updates!  I've elided the resolved issues in this
reply.

Sławomir Wójcik  writes:

> On 29.05.2020 05:22, Nicholas D Steeves wrote:
>> Sławomir Wójcik  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 
> ) is listed in the copyright entry and the 
> person which took over the project(galaunay 
> ) 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 

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

[Sławomir Wójcik]

On 29.05.2020 05:22, Nicholas D Steeves wrote:

Hi Sławomir,

Sławomir Wójcik  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 
) is listed in the copyright entry and the 
person which took over the project(galaunay 
) 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 
   * "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 de

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

[Nicholas D Steeves]

Hi Sławomir,

Sławomir Wójcik  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.
Push upstream version tags.
Copyright file issues:
  * 2 files stanzas are missing
  * 2 people are missing
  * at least 1 license is missing
  * always dedicate one line to each year[s] copyright_holder_name 
  * "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
  * 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.
  * missing dummy transitional package, Breaks, and Provides; at present
  an upgrade path has not been provided.
  
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.

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


signature.asc
Description: PGP signature

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

[Sławomir Wójcik]

On 22.05.2020 05:14, Nicholas D Steeves wrote:

Hi,

Sławomir Wójcik  writes:


Thanks for the quick reply,



You're welcome :-)  I'm happy I was able to--sometimes it may take a
while to reply.


On 21.05.2020 01:30, Nicholas D Steeves wrote:

Sławomir Wójcik  writes:

[snip]

The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.

I have imported from dsc by gbp-import-dsc in a new fresh repo, so I
should be able to merge my changes(basically replacing all debian/* files)


More or less, but it's a bit more involved than this, because a large
part of the work of maintaining a package is documenting that work.  At
a minimum, this means one must document changes from the previous
version in debian/changelog.  If you're maintaining the package in git
(highly recommended, and also generally expected for team packages),
then "good git hygiene" means each step is contained within a single
commit.

For example, updating a new upstream version should be one commit.
Adopting the package, or adopting it into the team, should be another.
Adding yourself to Uploaders should be another, etc.  As an example of
when it's ok to combine micro operations, I think it's ok to
combine changing debhelper to debhelper-compat and deleting
debian/compat in a "Switch to debhelper-compat $version" step.

Each of these actions must be documented in debian/changelog.

Your changelog entry (everything from the "package-name
(version-debian_revision)…" line at the top, to the " -- Your Name
 `date -R`" line should be appended to the top of the existing
changelog.  Generally I will use 'dch -v$upstream_version-1' for this.

" * Adopt package. (Closes: #ITA-bug-number)" should be the first line
of the entry.  Then "New upstream version." or "New upstream release.",
as you prefer, and additionally closing a bug if there's a bug
requesting a new version.  Then other items.

Finally, you're welcome to update the changelog all at once at the end,
as a separate commit.  Some people prefer to stage individual changelog
lines with the commit associated with the work.  You don't have to
follow that practise if you don't want to, but if you do then "magit"
can be used to do all your work at once, then stage and commit changes
into discrete commits.

All of this information should already be documented at:

   https://www.debian.org/doc/manuals/maint-guide
   https://www.debian.org/doc/manuals/debmake-doc

Please study those guides.  It's also recommended to look at other
packages from our team for hints, and to get a sense of what the
existing conventions are.  Fair warning: I was taught that " * Bump foo"
was an unacceptable practise.

If someone has a link in-hand to one of the conversations about
" * Bump foo" please share it!


-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?


The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.

Actually upstream project name is
emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode
) rather than
scala-mode-el, but I guess binary package name is more important for
debian users and if source package name will stay the same it won't be
such a big deal, right?


Exactly :-)  When I was a new member I also felt a strong inclination to
rename source packages to sate my desire for correctness, but after a
while I came to agree with more experienced developers; they expressed
to me the perspective that it was a waste of time, and after seeing my
packages wait for months in the "Debian NEW queue", waiting for an
ftpmaster to review the package, I came to understand that source
package renames burden the overworked/understaffed ftpmaster team with
extra work, for little gain.

For more info about why the binary package name is important, read the
dh-elpa and dh-make-elpa documentation, and feel free to ask for
clarification if anything there seems unclear.


-upstream version in existing package and most of debian files are very old
or outdated


Yup, that's part of the work of adopting a package that needs work ;-)


Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be
interested to
give his/her opinion.


If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

That would be great.

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

[Nicholas D Steeves]

Hi,

Sławomir Wójcik  writes:

> Thanks for the quick reply,
>

You're welcome :-)  I'm happy I was able to--sometimes it may take a
while to reply.

> On 21.05.2020 01:30, Nicholas D Steeves wrote:
>> Sławomir Wójcik  writes:
[snip]
>> The issue isn't the "repo" so much as continuity with the existing
>> source package.  Two people's occasional contributions over three years
>> are valuable, and erasing them from Debian history would be unjust.
> I have imported from dsc by gbp-import-dsc in a new fresh repo, so I 
> should be able to merge my changes(basically replacing all debian/* files)

More or less, but it's a bit more involved than this, because a large
part of the work of maintaining a package is documenting that work.  At
a minimum, this means one must document changes from the previous
version in debian/changelog.  If you're maintaining the package in git
(highly recommended, and also generally expected for team packages),
then "good git hygiene" means each step is contained within a single
commit.

For example, updating a new upstream version should be one commit.
Adopting the package, or adopting it into the team, should be another.
Adding yourself to Uploaders should be another, etc.  As an example of
when it's ok to combine micro operations, I think it's ok to
combine changing debhelper to debhelper-compat and deleting
debian/compat in a "Switch to debhelper-compat $version" step.

Each of these actions must be documented in debian/changelog.

Your changelog entry (everything from the "package-name
(version-debian_revision)…" line at the top, to the " -- Your Name
 `date -R`" line should be appended to the top of the existing
changelog.  Generally I will use 'dch -v$upstream_version-1' for this.

" * Adopt package. (Closes: #ITA-bug-number)" should be the first line
of the entry.  Then "New upstream version." or "New upstream release.",
as you prefer, and additionally closing a bug if there's a bug
requesting a new version.  Then other items.

Finally, you're welcome to update the changelog all at once at the end,
as a separate commit.  Some people prefer to stage individual changelog
lines with the commit associated with the work.  You don't have to
follow that practise if you don't want to, but if you do then "magit"
can be used to do all your work at once, then stage and commit changes
into discrete commits.

All of this information should already be documented at:

  https://www.debian.org/doc/manuals/maint-guide
  https://www.debian.org/doc/manuals/debmake-doc

Please study those guides.  It's also recommended to look at other
packages from our team for hints, and to get a sense of what the
existing conventions are.  Fair warning: I was taught that " * Bump foo"
was an unacceptable practise.

If someone has a link in-hand to one of the conversations about
" * Bump foo" please share it!

>>> -if we want to adhere to EmacsenTeam Addons packaging policy
>>> (https://wiki.debian.org/EmacsenTeam) and I think we should for better
>>> collaboration and consistency then the package name should be changed to
>>> elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
>>> should be marked as transitional dummy package installing new one, right?
>>>
>> The binary package name should be elpa-scala-mode, but the source
>> package should remain scala-mode-el.
> Actually upstream project name is 
> emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode 
> ) rather than 
> scala-mode-el, but I guess binary package name is more important for 
> debian users and if source package name will stay the same it won't be 
> such a big deal, right?

Exactly :-)  When I was a new member I also felt a strong inclination to
rename source packages to sate my desire for correctness, but after a
while I came to agree with more experienced developers; they expressed
to me the perspective that it was a waste of time, and after seeing my
packages wait for months in the "Debian NEW queue", waiting for an
ftpmaster to review the package, I came to understand that source
package renames burden the overworked/understaffed ftpmaster team with
extra work, for little gain.

For more info about why the binary package name is important, read the
dh-elpa and dh-make-elpa documentation, and feel free to ask for
clarification if anything there seems unclear.

>>> -upstream version in existing package and most of debian files are very old
>>> or outdated
>>>
>> Yup, that's part of the work of adopting a package that needs work ;-)
>>
>>> Please, let me know what should be done. As I pointed out here:
>>> https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
>>> it would be the best if someone from Debian Emacsen Packaging Team will work
>>> with me on this and other packages but maybe someone else will be
>>> interested to
>>> give his/her opinion.
>>>
>> If you proceed with this ITP I'd like to work with you and/or comaintain
>> it, because it's a block

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

[Sławomir Wójcik]

Thanks for the quick reply,

On 21.05.2020 01:30, Nicholas D Steeves wrote:

Hi Sławomir,

Thank you for your interest and initiative!

Sławomir Wójcik  writes:

[snip]

One issue is that I've created the repo from scratch because git repo is not
reachable, existing package have quite ancient upstream version and it's
debian
files(especially rules is obviously not using dh-elpa) are mostly outdated.

I can try to use gbp-import-dsc and recreate a new repo if it's really
necessary
or required but I don't see much value in it because:


The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.
I have imported from dsc by gbp-import-dsc in a new fresh repo, so I 
should be able to merge my changes(basically replacing all debian/* files)

-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?


The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.
Actually upstream project name is 
emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode 
) rather than 
scala-mode-el, but I guess binary package name is more important for 
debian users and if source package name will stay the same it won't be 
such a big deal, right?

-upstream version in existing package and most of debian files are very old
or outdated


Yup, that's part of the work of adopting a package that needs work ;-)


Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be
interested to
give his/her opinion.


If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

That would be great.


Best,
Nicholas

On 21.05.2020 01:49, Nicholas D Steeves wrote:

P.S.  Are you using the following as the new upstream source?:

   https://github.com/hvesalai/emacs-scala-mode

I've received confirmation this is the one smartparens requires.


Yes

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

[Nicholas D Steeves]

P.S.  Are you using the following as the new upstream source?:

  https://github.com/hvesalai/emacs-scala-mode

I've received confirmation this is the one smartparens requires.


signature.asc
Description: PGP signature

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

[Nicholas D Steeves]

Hi Sławomir,

Thank you for your interest and initiative!

Sławomir Wójcik  writes:

[snip]
> One issue is that I've created the repo from scratch because git repo is not
> reachable, existing package have quite ancient upstream version and it's 
> debian
> files(especially rules is obviously not using dh-elpa) are mostly outdated.
>
> I can try to use gbp-import-dsc and recreate a new repo if it's really 
> necessary
> or required but I don't see much value in it because:
>

The issue isn't the "repo" so much as continuity with the existing
source package.  Two people's occasional contributions over three years
are valuable, and erasing them from Debian history would be unjust.

> -if we want to adhere to EmacsenTeam Addons packaging policy
> (https://wiki.debian.org/EmacsenTeam) and I think we should for better
> collaboration and consistency then the package name should be changed to
> elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
> should be marked as transitional dummy package installing new one, right?
>

The binary package name should be elpa-scala-mode, but the source
package should remain scala-mode-el.

> -upstream version in existing package and most of debian files are very old
> or outdated
>

Yup, that's part of the work of adopting a package that needs work ;-)

> Please, let me know what should be done. As I pointed out here:
> https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
> it would be the best if someone from Debian Emacsen Packaging Team will work
> with me on this and other packages but maybe someone else will be 
> interested to
> give his/her opinion.
>

If you proceed with this ITP I'd like to work with you and/or comaintain
it, because it's a blocker for my smartparens ITP.

Best,
Nicholas


signature.asc
Description: PGP signature

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

[Sławomir Wójcik]

Hello,

I would like to adopt this package and hopefully maintain it as part of the
Debian Emacsen Packaging Team.

I've packaged it, the package is on debian mentors:
https://mentors.debian.net/package/emacs-scala-mode
and the repository is on salsa under my user for now:
https://salsa.debian.org/Valdaer/emacs-scala-mode

One issue is that I've created the repo from scratch because git repo is not
reachable, existing package have quite ancient upstream version and it's 
debian

files(especially rules is obviously not using dh-elpa) are mostly outdated.

I can try to use gbp-import-dsc and recreate a new repo if it's really 
necessary

or required but I don't see much value in it because:

-if we want to adhere to EmacsenTeam Addons packaging policy
(https://wiki.debian.org/EmacsenTeam) and I think we should for better
collaboration and consistency then the package name should be changed to
elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el
should be marked as transitional dummy package installing new one, right?

-upstream version in existing package and most of debian files are very old
or outdated

Please, let me know what should be done. As I pointed out here:
https://lists.debian.org/debian-emacsen/2020/05/msg00039.html
it would be the best if someone from Debian Emacsen Packaging Team will work
with me on this and other packages but maybe someone else will be 
interested to

give his/her opinion.

Regards,
Sławomir Wójcik