Path: csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod From: Jeremy Stanley Newsgroups: linux.debian.maint.python Subject: Re: a few quick questions on gbp pq workflow Date: Mon, 07 Aug 2017 00:30:02 +0200 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Aug 6 22:20:53 2017 Old-Return-Path: X-Amavis-Spam-Status: No, score=-10.901 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DIGITS_LETTERS=1, FOURLA=0.1, LDO_WHITELIST=-5, PGPSIGNATURE=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -6.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6YayAov9Y+xpuyut" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Sa-Exim-Connect-IP: 2001:4802:7801:102:be76:4eff:fe20:63e0 X-Sa-Exim-Rcpt-To: debian-python@lists.debian.org X-Sa-Exim-Mail-From: fungi@yuggoth.org X-Sa-Exim-Scanned: No (on azathoth.yuggoth.org); SAEximRunCond expanded to false X-Mailing-List: archive/latest/15096 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20170806222030.GB2409@yuggoth.org Approved: robomod@news.nic.it Lines: 116 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sun, 6 Aug 2017 22:20:30 +0000 X-Original-Message-ID: <20170806222030.GB2409@yuggoth.org> X-Original-References: <20170806153751.GW2409@yuggoth.org> <39436F23-8AC3-4D53-908C-C87DCA12B8A9@kitterman.com> <20170806185344.GX2409@yuggoth.org> Xref: csiph.com linux.debian.maint.python:9715 --6YayAov9Y+xpuyut Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-08-06 17:24:59 -0400 (-0400), Ondrej Novy wrote: [...] > Lintian considers this as "bug": > https://lintian.debian.org/tags/source-contains-prebuilt-sphinx-documenta= tion.html > (pedantic, I know). [...] I'll can't help but ponder why lintian should have _pedantic_ opinions on upstream tarballs. Policy violations from upstream, yes; being picky about contents of the debian dir, sure; but nit-picking what's in an otherwise DFSG-compliant upstream tarball? I guess it's so you can let upstream know in case they might have made a mistake in their release process, but the obsession from some (particularly new) maintainers with making their packages lintian --pedantic clean makes me suspect this does more harm than good in the long run if it encourages them to needlessly filter and repack just to silence the most benign of low-level warning messages. > But they want to keep generated (read: useless for our orig tarballs) > things inside release tarballs. Well, OpenStack release tarballs don't include HTML documentation in the sdist anyway so this is a bit tangential to the thread, but I for one will happily put my weight behind solving whatever issues in those tarballs actively prevent Debian from being able to use them. > And sdist orig tarballs are too big, because they contains > prebuild things, FTP masters are not happy. (Thomas words). >=20 > Context: > http://lists.alioth.debian.org/pipermail/openstack-devel/2017-July/021447= =2Ehtml > ... I've been already flamed by the FTP masters because small > packages like nova-compute-* became insanely huge (ie: megs instead of > kbytes). ... Thomas references the AUTHORS and ChangeLog files (which embed important metadata from the revision control system into the release tarball, far from useless in my opinion); but taking the nova-15.0.0.tar.gz release for example, those two files account for a total of 5% of the unpacked tree according to du and probably compress fairly well. By comparison, the unit tests and fixtures make up 42% of the size of the tree on their own. He's also referring to a situation from _years_ ago, which was subsequently changed after he asked... those current tarballs only include author names and very abbreviated information parsed out of the git log and have been that way since 2013 (pbr commit 94a6bb9 released in 0.6), but mentioning that would likely have undermined his argument. It's the charge of the FTP masters to push back and ask questions when they see something they think may be in error, and the responsibility of developers to fix things OR explain the situation to their satisfaction. I'm unsurprised they raised an eyebrow at the size of the old nova changelogs, and this was addressed upstream as a serious concern (I was heavily involved in the work to make that happen, and glad to do it). As I said, I will personally invest substantial effort to remove roadblocks in the way of any Debian maintainer's use of whatever OpenStack release artifacts would serve their workflows best, but I much prefer to base decisions on where to spend my time on factual data rather than vague assertions which may no longer be relevant. > I consider git repository to be better source of "source code" > than sdist, which is built from that same git. But it's just about > POV :). I know others share that opinion too, but as above if I `apt-get source nova` the unpacked tree doesn't provide me with information on who the upstream authors are, nor a detailed changelog of how it differs from prior releases... and no way to build that information =66rom the tree. This seems to me like important information a user might care about as a recipient of the source code. I get that most users who want that will probably have access necessary to git clone the repo, but Debian also isn't about just satisfying the majority. It's your prerogative as a package maintainer to use your best judgement and choose whatever workflows suit you, obviously. I simply want to make sure that OpenStack (or any other project I contribute to for that matter) gives distros flexible options, and that you base your decisions as to what to use on research and fact rather than hearsay. --=20 Jeremy Stanley --6YayAov9Y+xpuyut Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJZh5YuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5N0FFNDk2RkMwMkRFQzlGQzM1M0IyRTc0 OEY5OTYxMTQzNDk1ODI5AAoJEEj5lhFDSVgp4J8QAI1RvGn3gc/asIuVZhIt3AUG 291gaYcfyg98gzg6oV8ocQyJQlsEHLE/MZcwP5z36dB/2fAVXG/hHo0hDabUtgL1 r9nryFWC5qPohiFFTap0yUpCOj/oUGpjoOkgP5kJ/zbfEbifi0NAFmFH1cvOlo2f DVoz4uX7U6TZ1wl3DkplE66jocwn+zy/ocGFaXgYNokBES+drqO14N8pW9QwCfBD VB+NW8IiU87Yg5SrDzRy5Jk+dos/Z+RmSlRGqD1PgMCKLX48+SdcLYlQlVM6XOtz 5Ijx/dbomo00jIHPkE3yzpBfbZ4NJwrbD6aIfH6GjEwya2HlKVkKxh92ZFsQBZmW iD0sLL8l9FI0GL7zIv3Q8ujp0YOIiX/IMFWZNYOIU+fosoOuNeYYKGtDti4zBFcA FXVSbO54toTnMmDQBXJg0yP4ODUQJJ7IJyZlfOKE0pII7pKHY0RePnpyv/o5sZav u2R7rZcIjfHYA1UFuPj71lqDVCfb2aZxEDSmhkDpp1Y+4ZJydscoDA50lPCj6HAT OemAWMVw+jfb0cpBj9pLEb8L0Y2mD6FM13XU31HmFBgtsFQLXr9zlFxEQkgwICyI MhVhkaVTuWh28jDlnthl6T0huyfnl7BCONu8uBZqoseTiNjDYmMiPu06vik3RqY9 Dx+6WXf7IBCUoLOQzXFJ =3sF6 -----END PGP SIGNATURE----- --6YayAov9Y+xpuyut--