[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#945447: RFS: emacs-websocket/1.12+1.g74e4b82-1 [ITP] -- Emacs WebSocket client and server



Hi Antoine,

Antoine Beaupré <anarcat@debian.org> writes:

> A few comments...
>
> Why do you specify a compression level and algorithm in gbp.conf?
>
> compression = xz
> compression-level = 9
>

This reduces the incidence of encountering an annoying gbp bug, where
gbp fails, allegedly because "two tarballs were found", even when the
tarball did not previously exist on disk and is generated on demand from
upstream tag.  Other than that it's harmless and redundant, because
these settings are now gbp defaults.

> Upstream doesn't seem to use any peculiar tarball format, so that
> generated tarball won't match the one published on github.
>

I'm using release tags directly and not github generated & published
tarballs ("why" is another discussion).  The reason the Emacsen Team
requests a tarball in d/watch is because the git mode we previously used
was too resource-intensive.  The bug mentioned above also has a useful
(hack of a) side-effect in that it seems to enforce new upstream version
imports from git tags rather than github-generated tarballs.  Whenever
the "light" git-mode becomes generally recommended and preferred over
the tarball one I'll switch my upstream-uses-github packages over to it.

> I also wonder if it's really necessary to ship a git snapshot instead of
> the 1.12 release... I see it includes a patch to tweak the GPL version,
> is that why that was done?
>

For multiple past NEW packages, ftpmasters have asked me to contact
upstream about licensing problems (eg: we're accepting, but you need to
do xyz), so I started doing this preRFS.  Then lamby asked me not to
carry licensing-related-changes as a quilt patch--with good rationale
that I agree with.  Thus, packaging a git snapshot.  The contradictory
declared license issue is here:

https://github.com/ahyatt/emacs-websocket/issues/62

> Are the tests included in the package build? or autopkgtest? could that
> be done? Not a blocker.
>

Sorry, I don't understand what you mean...  ERT tests are already run
during the build, autopkgtest-pkg-elpa has been activated
(d/control:L12), I've confirmed autopkgtest runs the tests, and I've
also opened an upstream issue about integrating the functional tests
into the ERT framework:

https://github.com/ahyatt/emacs-websocket/issues/64

Since all NEW packages now require two uploads before they can enter
testing, I like to add value to the second upload, and the following
brand new commit seems like a good candidate for this:

https://github.com/ahyatt/emacs-websocket/commit/69ee80a88ba825a925e82a5576a340b3ec03fd51

Depending on how long it takes this package to pass NEW upstream might
tag a new release including that commit, which would be ideal for the
second upload!

> Otherwise looks good.
>

Thanks for reviewing :-)  'hope my reply sufficiently addresses your
concerns!


Cheers,
Nicholas

Attachment: signature.asc
Description: PGP signature


Reply to: