Re: Python Policy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)" <umlaeute@debian.org> writes:
>
>> thanks a lot for preparing all this.
>>
>> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
>>> +DPMT requires upstream tarballs; releases cannot be made from
>>> upstream git +repositories directly. This is because PyPI
>>> contains upstream tarballs, and +tarballs are what we upload to
>>> the Debian archive.
>>
>> i find the justification a bit weird: "no releases can be made
>> from upstream git because some upstreams use tarballs"?
>
> Yes, that is weird, and it's not what you quoted. I don't know how
> you get that meaning from the text you quoted
it's not what i quoted, but it's what i read in the quote.
it says "releases cannot be made from upstream git repositories
directly. This is because PyPI contains upstream tarballs [...]".
i fail to see what this "this" in the second sentence refers to if it
was not for the statement in the first sentence. thus creating a
cause-effect statement "pypi contains upstream tarballs -> releases
cannot be made from upstream git".
i think this logic is plain wrong.
for one thing, pypi - while being the most prominent source - is
probably *not* the only source for python modules. (that's why my
interpretation says "some upstreams").
furthermore, pypi is *not* upstream itself. it's a distribution
channel. an upstream (author) might as well do releases using git-tags
on github in addition to uploading the tarballs to pypi.
in this case, releases *can* (technically) be made from git tags.
it also says "[...] and tarballs are what we upload to the Debian
archive.".
which is true, but it's true for any Debian package (even those that
use upstream git or zip). so what's the point?
so: if my upstream does not use pypi (or i'm not aware of upstream
using pypi), does "tarballs required" policy still apply to me?
i think yes (but then i don't understand why there's a rationale if it
does not apply)
> This is because PyPI contains upstream tarballs, and tarballs are
> what we upload to the Debian archive.
>
>> in any case, i don't think that there is actually a need for the
>> policy to justify the decision to require tarballs (let's put
>> that in the wiki for those interested).
>
> On the contrary, I think the Policy document should document the
> rationale for contingent decisions like this. When it is
> inevitably discussed again in the future, it is always better to
> know the intent of the authors.
that's why i said that the rationale should be documented in the wiki
(as opposed to the policy).
the policy did not contain a rationale why we chose svn.
the policy doesn't contain a rationale why we chose git.
(well, the decision for git will probably go unquestioned, but:)
the policy doesn't contain a rationale why we chose git-dpm (not even
a shallow one as "we need *a single* standard", let alone one that is
based on actual technical merits).
TL;DR
i am not a native speaker. so i might get things wrong.
but i'm not the only non-native English speaker in Debian.
therefore, i *strongly* suggest that the policy should be written in a
style that non-natives can understand it - without getting the
impression that considerable parts of the policy are only relevant for
specific setups (and not for them).
mfgsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWJ0P+AAoJELZQGcR/ejb4XtsQAIKQXQZxlzSgJF6zOi6NTgX8
Yq/y3mgvOZkWwsgOSqZKFVEnSsPQdBDptywSqV1Fm1Dy/6MS68jy03JRP+zWBUV1
n0Hr2NiMYzQxGBOhmIIrR7WtdEvxXhOs1Z1A3Nv5Tq4lJYX0XBPfAxOus/jdii6g
w84EIACtR6unvhGEcbABx8jNAecX73azN0Uni0S4BCYpczHgSEghulBu5FK4FT1M
22ZKA40S9kvq4naLg43A/hGjXsLvd//6Bfn5Cufu3YaAXugSaqIz16cNlzTKZDRq
F3NUtUtLD6RdjkCtzpAIo4WoUMZcvprXh34EVctj7uJ+tSYDi17J1dUO8HOTq3UI
EOEDFOscQvQZ+6h//89W6QjDdK8wW2C4jnspOQx6ZD4dJKa6r0qCKvBgx/E2fnmX
rb568XMXErGcjdLRAAyJj50UYud3uqNdRvjg6mrgQdRPghSFAQXz4jjx9W0y2bh8
MrC7BaaLA9nS3XdSMVwQWGMQJ4Nn+LTrWtBhnjLAEee1pWg5x4wdamLAPGKCyWN2
NYHweYdcGuEAeoYr5T9tpEsnRZQo6kIE+jRKp0IX88JGLqdv1eyy+/gk+mYtSkTY
Qie0dvzTUs4btwI3To1g2X6oCRaBMabm0sZ4/yLZBqpSC9NdrB3YAsBRX3xWMgEg
2DCyuPCVFKHWUp1Pz++T
=sKPF
-----END PGP SIGNATURE-----
Reply to: