Bug#861125: ITP: elpa-writegood-mode -- Minor mode for Emacs to improve English writing
Hi Antoine and Sean,
If you don't know each other yet, I'll just say that you two of the
most friendly and patient people I've met through Debian.
Sean, I've CC'ed you because Antoine expressed interest in joining the
pkg-emacsen team, and he asked me a couple of questions about dh-elpa
and dh-make-elpa that I couldn't answer. I'd be happy to work your
replies into a documentation patch, or a wiki page if you're busy.
The questions we need help with are at 2. and especially 4.
On 25 April 2017 at 19:07, Antoine Beaupré <anarcat@debian.org> wrote:
> On 2017-04-25 18:27:11, Nicholas D Steeves wrote:
>> On Tue, Apr 25, 2017 at 01:37:12PM -0400, Antoine Beaupré wrote:
>>> On 2017-04-25 11:17:28, Nicholas D Steeves wrote:
>>> >
>>> > It will take some time to learn how this one works, but another reason
>>> > I'm interested in maintaining writegood-mode is I'm certain I can
>>> > contribute to it. Preliminary packaging is here:
>>> > ssh://git.debian.org/git/pkg-emacsen/pkg/writegood-mode.git
>>>
>>> Excellent. Same remark than writeroom about uploading to
>>> mentors.debian.net. :) But it's great you pushed into git!
>>>
>>> (It's just that I'm lazy: mentors.debian.net shows lintian output for
>>> me... ;))
>>
>> I've uploaded a package for review. Since I'm still a DM, would you
>> please sponsor it if it looks good? I'd be happy to add you to
>> uploaders, if you'd like.
>>
>> https://mentors.debian.net/package/writegood-mode
>> dget -x https://mentors.debian.net/debian/pool/main/w/writegood-mode/writegood-mode_2.0.2-1.dsc
>
> thanks!
>
> here's a short review.
>
> 1. the package's description doesn't mention "emacs" or "english" - in
> the original RFP, i used this instead:
>
> Description : Minor mode for Emacs to improve English writing
> This is a minor mode to aid in finding common writing
> problems. Matt Might’s weaselwords scripts inspired this mode.
> .
> It highlights text based on a set of weasel-words, passive-voice
> and duplicate words.
My apologies, I failed to scrutinise the differences between the
description you provided and the one dh-make-elpa generated. I've
merged your copy and credited you in d/copyright. D/* uses the same
license as upstream package, which you said was your preference in
another thread, so I assume this is ok. By the way, dh-make-elpa and
gbp make it really easy to do these packages. From the manpage (plus
addition of the gbp repo creation)
% git clone -o upstream https://foo.org/foo.git
% cd foo
% git reset --hard 1.0.0 # package latest stable release
% dh-make-elpa --pkg-emacsen
% git add debian && git commit -m "initial Debianisation"
% git deborig
% dpkg-buildpackage -us -uc
% gbp create-remote-repo --remote-url-pattern=ssh://git.debian.org/git/pkg-emacsen/pkg/foo.git
> 2. that version patch - really necessary? if upstream screwed up their
> versioning, it's kind of their problem no? since it's just a
> cosmetic change, I would avoid it, personnally.
Is it just a cosmetic change? I chose to be cautious out of ignorance
of how elpa/MELPA works, because I wonder if it uses this versioning
to decide whether to download local-to-$USER updates. We don't
recommend that users mix packaging systems like this, of course, and I
guess it could be argued that if the system provided version
(unpatched is 2.1) is higher than the upstream one (2.0.1), then MELPA
would refuse to download locale-to-$USER updates until upstream tagged
2.1.0. I plan to drop a similar patch for writeroom-mode, because the
convention of most of these upstreams seems to be to only increment
major and minor versions but not patch-level versions.
> 3. if you still think it's necessary, explain *why* it is there in the
> changelog, not just "it's there". :) same in the patch: not "what"
> but "why" in commitlogs...
" * Add filename.patch for maximal correctness and just to be extra
safe" didn't seem like a strong enough case, and I prefer to do the
work when I have time and revert if unnecessary. If it's truly just
cosmetic I'll drop it. 'good for some gbp pq practice and another
lesson in how *self describing file names are not sufficient for
debian changelogs* ;-)
> 4. picking a random elpa package (elpa-helm), i notice it depends on
> "emacs" while yours depend on "emacs-common" - why? and why the
> versioned dependencies?
>
> https://anonscm.debian.org/git/pkg-emacsen/pkg/helm.git/tree/debian/control
My best guess is it's the difference between a package converted to
elpa vs a package created with dh-make-elpa, and I Sean has reasons
for generating versioned dependencies by default. This is actually
one of the reasons I was paranoid about 2. ;-)
> I'm not very familiar with "elpa" packages, so I don't know if it works
> or not - did you actually test this? :)
Yes, and I was surprised to see teal squiggly lines appear...for
passive voice :-o Also, at the moment, the versioned dependencies for
sid can be satisfied on stretch. (I built in a sid cowbuilder but
installed on stretch).
Cheers,
Nicholas
Reply to: