Re: Bug#819681: RFS: python-django-gravatar2/1.4.0-1 [ITP]
Pierre-Elliott,
On 7 April 2016 at 12:27, Pierre-Elliott Bécue <becue@crans.org> wrote:
> You're right, but I'm an "explicit is better than implicit guy". :)
I guess this is not a case of "explicit vs. implicit". Imagine the
entire line as an URL:
https://github.com/P-EB/python-django-gravatar2.git%20-b%20master
Of course you wouldn't have a problem if you copy-and-pasted it
(before escaping the spaces) on the command line, as the "-b master"
would be interpreted as arguments to "git clone". But, if you copy and
pasted on another client, e.g. a GUI Git client (which I've seen
people using), the URL may be interpreted like above (after escaping)
and the cloning process will fail.
Not to mention that this is expected to be in machine-readable form,
which may not be aware that someone is passing Git command line
arguments along the URL.
> I thought it'd be better to keep them, but, okay.
They are mostly related to building projects written in C, so there's
little use for a pure-Python one, as you are not "saving them for
later".
> I'm not in fond of PYBUILD_NAME thing since I met a lot of trouble with it.
> If that's recommended I'll put it but I'm more a ".install" files guy.
Imagine that you would be doing by hand what is expected to be
automated by Pybuild.
> I do not have any issue to build multiple times, but I'll follow your
> advice.
Are you building with pbuilder or something like that? I've used
dpkg-buildpackage and it complained in the second time I ran it.
> I'm really uncomfortable with tests un packaging for python apps, but I can
> try to remove the override. Anyway, I'm using pybuild, hence the pypi
> package fits better and a good way to have a snapshot of upstream's work.
Why uncomfortable with tests in packaging? They can help to make sure
that newer versions aren't introducing regressions.
I didn't understood why PyPI packages would fit better than snapshots
(tarball releases) from the upstream repository.
> Thank you very much for all these advice.
Glad to help. You're welcome.
On 7 April 2016 at 12:51, Pierre-Elliott Bécue <becue@crans.org> wrote:
> I uploaded a new version of the package. It should be visible soon, and
> accessible also via
>
> dget -x http://mentors.debian.net/debian/pool/main/p/python-django-gravatar2/python-django-gravatar2_1.4.0-2.dsc
You shouldn't bump the version of the package yet, as it was never
uploaded to the archive. Until the first upload, it will be "X.Y.Z-1",
no matter how many changes you did to it. Then you can bump the
version in the following revisions, but only after every upload, not
after every change in the packaging work.
P.s.: I've seen that you pushed changes with "--force" to the Git
repository. Please don't do that when you already shared it with other
people. They will not be able to merge/pull easily (as there are
annoying merge conflicts in the changed files) and will be harder to
analyze what you really did (which is the primary feature of every
version control system), as there will be no visible difference in the
history.
Regards,
Tiago.
--
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil
Reply to: