Bug#993499: RFS: python-marshmallow-polyfield/5.10-1 -- marshmallow extension for polymorphic fields

1 view
Skip to first unread message

Diego M. Rodriguez

unread,
Sep 2, 2021, 5:20:03 AMSep 2
to
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-marshmallow-polyfield":

* Package name : python-marshmallow-polyfield
Version : 5.10-1
Upstream Author : Matt Bachmann <bachma...@gmail.com>
* URL : https://github.com/Bachmann1234/marshmallow-polyfield
* License : Apache-2.0
* Vcs :
https://salsa.debian.org/python-team/packages/python-marshmallow-polyfield
Section : python

It builds those binary packages:

python3-marshmallow-polyfield - marshmallow extension for polymorphic
fields

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/python-marshmallow-polyfield/

Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/p/python-marshmallow-polyfield/python-marshmallow-polyfield_5.10-1.dsc

Changes since the last upload:

python-marshmallow-polyfield (5.10-1) UNRELEASED; urgency=medium
.
[ Ondřej Nový ]
* d/control: Update Maintainer field with new Debian Python Team
contact address.
* d/control: Update Vcs-* fields with new Debian Python Team Salsa
layout.
.
[ Diego M. Rodriguez ]
* New upstream version 5.10
* d/watch: version 4, use signature
* d/control: bump Standards-Version to 4.6.0 (no changes needed)
* d/control: set architecture to all

Regards,
--
Diego M. Rodriguez

Jeroen Ploemen

unread,
Sep 16, 2021, 10:10:03 AMSep 16
to
Control: tags -1 moreinfo

On Thu, 2 Sep 2021 11:09:06 +0200
"Diego M. Rodriguez" <di...@moreda.io> wrote:

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package
> "python-marshmallow-polyfield":

copyright: where does the 2015 upstream copyright year come from?

control:
* why hardcode the dependency on python3-marshmallow for the binary pkg?
* the build-dep on the same also seems unneeded (at least unless/until
tests are re-enabled, see watch)

watch: consider using github for upstream releases, as the files
published there include the upstream testsuite missing on pypi. And then
put those tests to good use, of course :)


Please remove the moreinfo tag (and CC me directly) once you have an
updated package ready.

Diego M. Rodriguez

unread,
Sep 17, 2021, 5:00:03 AMSep 17
to
Control: tags -1 - moreinfo

Hello Jeroen,

and thanks for the review!

> copyright: where does the 2015 upstream copyright year come from?

I think it was added during the initial packaging based on the year of
the first upstream public release, but indeed there is no explicit
mention of 2015 in the upstream sources. I have added a comment to
d/copyright, but I'm not sure if this is the best approach - any
guidance would be welcome.

> control:
> * why hardcode the dependency on python3-marshmallow for the binary pkg?

Unintentional - and fixed.

> * the build-dep on the same also seems unneeded (at least unless/until
> tests are re-enabled, see watch)
>
> watch: consider using github for upstream releases, as the files
> published there include the upstream testsuite missing on pypi. And then
> put those tests to good use, of course :)

Switched to using github releases, re-enabling the tests during build
and also adding autopkgtests.


Thanks,
--
Diego M. Rodriguez

Jeroen Ploemen

unread,
Sep 17, 2021, 5:40:03 AMSep 17
to
On Fri, 17 Sep 2021 10:53:40 +0200
"Diego M. Rodriguez" <di...@moreda.io> wrote:

> > copyright: where does the 2015 upstream copyright year come from?
>
> I think it was added during the initial packaging based on the year of
> the first upstream public release, but indeed there is no explicit
> mention of 2015 in the upstream sources. I have added a comment to
> d/copyright, but I'm not sure if this is the best approach - any
> guidance would be welcome.

In that case, for lack of a better option, the upstream git commits could
serve as a basis for the years.

Diego M. Rodriguez

unread,
Sep 17, 2021, 8:20:04 AMSep 17
to
On Fri, 17 Sep 2021 11:30:24 +0200 Jeroen Ploemen <jc...@debian.org> wrote:
> In that case, for lack of a better option, the upstream git commits could
> serve as a basis for the years.

Noted - in this instance, 2015 is also the date of the initial git
commit in the upstream repo. Could you let me know if your mention of
"years" implies also declaring the year of the last commit for this
release in d/copyright (ie. 2015-2021)?

Jeroen Ploemen

unread,
Sep 17, 2021, 11:10:03 PMSep 17
to
On Fri, 17 Sep 2021 14:09:54 +0200
"Diego M. Rodriguez" <di...@moreda.io> wrote:

It does. Copyrights have expiry dates too, so the most recent year matters.

Diego M. Rodriguez

unread,
Sep 18, 2021, 11:30:03 AMSep 18
to
On Sat, 18 Sep 2021 05:06:59 +0200 Jeroen Ploemen <jc...@debian.org> wrote:
> It does. Copyrights have expiry dates too, so the most recent year matters.

Thanks - I updated the copyright line in order to include the most
recent year as well, along with the comment.

--
Diego M. Rodriguez
Reply all
Reply to author
Forward
0 new messages