Re: Salsa repository and first upload of tinyarray

2020-08-26 Thread Christoph Groth
Hello,

A long time ago, I opened an ITP [1] for Kwant, a Python library for
quantum physics computations that is popular with researchers in the
field.  Since we, the developers of Kwant, are running our own Debian
package repository, there was not much pressure to migrate the packages
into Debian proper, but finally as a new big Kwant release is taking
shape, I would like to finish the work and phase out our own repository.
(In order to be able to do that we will have to provide backports so
that people running Debian stable will be able to use up-to-date Kwant,
but I suppose that this should be possible.)

As a first step I would like to package the library tinyarray [2].
Ondrej Novy was so kind to create a repository on salsa [3] to which
I had pushed my packaging efforts.

I noticed that since then Ondrej did some small modifications to the
packaging.

In the following, I would like to take up the discussion that got
interrupted in August 2018:

Ondrej Novy wrote on 22 Aug 2018:

> st 22. 8. 2018 v 14:04 odesílatel Christoph Groth 
> napsal:
>
> > trusting PyPI to store the official release tarballs...
>
> trusting PyPi store without PGP signature is really bad idea.
>
> > I've also kept the full upstream history in the upstream branch,
> > assuming this to be more robust and powerful.  For example, this
> > allows to directly cherry-pick commits into the patch queue.
>
> you can cherry-pick commits into pq even without full upstream history
> in salsa git, using second remote.
>
> > Since both these practices are discouraged by the policy, I'm ready
> > to give them up, but before I spend time working on it, I would like
> > to ask
>
> I prefer to have git layout according to DPMT policy. There are
> reasons for it.

So, it seems to me that I should proceed as follows:

* Create a new packaging repository that follows DPMT policy in the
  above two points.

* Update it with the packaging modifications that have been done so far.

* Push the new repository to salsa.  Is there some recommended way to
  get rid of all the old branches and tags?  Perhaps creating a new
  repository on salsa (and renaming / deleting the old one) would be
  good solution?

Thanks
Christoph

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886418
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886628
[3] https://salsa.debian.org/python-team/modules/python-tinyarray



Re: Salsa repository and first upload of tinyarray

2018-08-22 Thread Ondrej Novy
Hi,

st 22. 8. 2018 v 14:04 odesílatel Christoph Groth 
napsal:

> trusting PyPI to store the official release tarballs...
>

trusting PyPi store without PGP signature is really bad idea.

I've also kept the full upstream history in the upstream branch,
> assuming this to be more robust and powerful.  For example, this allows
> to directly cherry-pick commits into the patch queue.
>

you can cherry-pick commits into pq even without full upstream history in
salsa git, using second remote.

Since both these practices are discouraged by the policy, I'm ready to
> give them up, but before I spend time working on it, I would like to ask
>

I prefer to have git layout according to DPMT policy. There are reasons for
it.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B


Re: Salsa repository and first upload of tinyarray

2018-08-22 Thread Piotr Ożarowski
> I've also kept the full upstream history in the upstream branch,
> assuming this to be more robust and powerful.  For example, this allows
> to directly cherry-pick commits into the patch queue.

you can add remote repository and cherry-pick upstream commits as you
like

> Since both these practices are discouraged by the policy, I'm ready to
> give them up,

please do

> but before I spend time working on it, I would like to ask
> whether tinyarray could be exempt from any one of both rules.  According
> with the policy, I would provide a debian/README.source file with the
> above rationale and instructions.

having one workflow makes it a lot easier to work on team packages,
please don't add exceptions if they're not really needed
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645



Re: Salsa repository and first upload of tinyarray

2018-08-22 Thread Christoph Groth
Hello,

Ondrej, thank you for the quick reaction.  I've read the policy.  So far
(for my unofficial packages) I haven't been using pristine tar tool,
trusting PyPI to store the official release tarballs.  The package is
configured such that the pristine tars can be downloaded using the
command 'gbp import-orig --uscan'.  I find this approach more elegant
compared to the hack that is pristine-tar.

I've also kept the full upstream history in the upstream branch,
assuming this to be more robust and powerful.  For example, this allows
to directly cherry-pick commits into the patch queue.

Since both these practices are discouraged by the policy, I'm ready to
give them up, but before I spend time working on it, I would like to ask
whether tinyarray could be exempt from any one of both rules.  According
with the policy, I would provide a debian/README.source file with the
above rationale and instructions.

Thanks,
Christoph


signature.asc
Description: PGP signature


Re: Salsa repository and first upload of tinyarray

2018-08-22 Thread Ondrej Novy
Hi,

st 22. 8. 2018 v 10:28 odesílatel Christoph Groth 
napsal:

> Would someone be so kind to create a repository on salsa.debian.org for
> Tinyarray and put it under group maintenance by the debian-python team?
> I am cwg-guest on salsa, but so far I'm not even a Debian contributor.
> Still, being the main author of Tinyarray, I commit myself to maintain
> the packaging.
>

https://salsa.debian.org/python-team/modules/python-tinyarray

enjoy :)

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
Jabber: on...@njs.netlab.cz
ICQ: 115-674-713
Facebook: http://www.facebook.com/onovy
Tel/Cell: +420 777 963 207
Datová schránka: aypqr6c