devel/py-gitpython: Update to 2.1.9

[ygy]

Summary

- Update devel/py-gitpython to 2.1.9
- Take maintainership

PR: 227017
Approved by: woodsb02, [e-mail] (maintainer timeout)
Differential_Revision: https://reviews.freebsd.org/D14899

Test Plan

testport: OK (11.1-RELEASE amd64, 10.4-RELEASE i386)
bulk build: OK (11.1-RELEASE amd64) for:

devel/py-git-up
devel/py-git_semver
security/w3af

[woodsb02]

Hi ygy,
This review is marked as "changes planned" - was this deliberate? If so, can you describe the problems you have found which are planning to address?
Cheers,
Ben

[ygy]

In D14899#313761, @woodsb02 wrote:

Hi ygy,
This review is marked as "changes planned" - was this deliberate? If so, can you describe the problems you have found which are planning to address?
Cheers,
Ben

I'm waiting for a (possible) maintainer timeout to take it over :-) It's been two timeouts.

[mat]

Then just change the maintainer and wait for one timeout, it is enough.

[mat]

I am not sure what the "3 consecutive times" adds here, could you explain?

[ygy]

In D14899#326603, @mat wrote:

I am not sure what the "3 consecutive times" adds here, could you explain?

From https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html:

If the maintainer does not respond within three months, or if there have been three consecutive timeouts, then that maintainer is considered absent without leave, and can be replaced as the maintainer of the particular port in question.

I realized that the statement could probably be omitted here, but I just wanted to address that. Do you have a better suggestion for this circumstance?

[mat]

In D14899#327870, @ygy wrote:

In D14899#326603, @mat wrote:

I am not sure what the "3 consecutive times" adds here, could you explain?

From https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html:

If the maintainer does not respond within three months, or if there have been three consecutive timeouts, then that maintainer is considered absent without leave, and can be replaced as the maintainer of the particular port in question.

I realized that the statement could probably be omitted here, but I just wanted to address that. Do you have a better suggestion for this circumstance?

Well, this sentence is not there for that purpose. This sentence means that if there are three consecutive timeouts, the maintainership can be reset to whatever is needed, most of the time, ports@ or any generic maintainer like perl@ or python@, and the previous maintainer cannot complain about it.

But any patch can be applied after only one maintainer timeout, including one which changes the maintainership.

[ygy]

In D14899#327968, @mat wrote:

In D14899#327870, @ygy wrote:

In D14899#326603, @mat wrote:

I am not sure what the "3 consecutive times" adds here, could you explain?

From https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer.html:

If the maintainer does not respond within three months, or if there have been three consecutive timeouts, then that maintainer is considered absent without leave, and can be replaced as the maintainer of the particular port in question.

I realized that the statement could probably be omitted here, but I just wanted to address that. Do you have a better suggestion for this circumstance?

Well, this sentence is not there for that purpose. This sentence means that if there are three consecutive timeouts, the maintainership can be reset to whatever is needed, most of the time, ports@ or any generic maintainer like perl@ or python@, and the previous maintainer cannot complain about it.

But any patch can be applied after only one maintainer timeout, including one which changes the maintainership.

Oh now I understand. I will rewrite the message then, thanks for the explanation!

[woodsb02]

Hi Guangyuan,
According to https://www.freshports.org/devel/py-gitpython, there are 3 ports which depend on this port:
devel/py-git-up
devel/py-git_semver
security/w3af

Can you please:

1. Bump the PORTREVISION variable of these dependent ports (adding a line to the Makefile if it is not already there), and include these changes in this review
2. Run poudriere bulk -t on these dependent ports with your updated version of devel/py-gitpython, and bumped PORTREVISIONS, and report the success in the “test plan” section of this review.
3. Have you been able to conduct any runtime testing of this updated port to confirm it functions ok (not always possible depending on familiarity with a port, but good to document in the “test plan” section one way or the other).

Thanks,
Ben

[mat]

Why bump dependant ports?

[woodsb02]

In D14899#328651, @mat wrote:

Why bump dependant ports?

Fair challenge - for the record Guangyuan this is related to section 5.2.3.1 of the porters handbook.

My thought process was to ensure the dependent ports get upgraded by pkg to ensure they keep working if they have any compiled code which depends on the old version of devel/py-gitpython.

However, given this python port does not install shared libraries, I don’t believe this step (item 1 in my list above) is required.

[ygy]

@woodsb02 @mat Noted and updated the test plan. I will include these in future reviews.

[woodsb02]

Approved for you to commit.

In the commit message, I believe it is preferred to have one line for each person who approved/reviewed. So please copy the “approved by:” line in the commit template, to look like:
Approved by: [e-mail] (maintainer timeout)
Approved by: woodsb02 (ports)

Nice work Guangyuan!

[mat]

In D14899#331877, @woodsb02 wrote:

Approved for you to commit.

In the commit message, I believe it is preferred to have one line for each person who approved/reviewed. So please copy the “approved by:” line in the commit template, to look like:
Approved by: [e-mail] (maintainer timeout)
Approved by: woodsb02 (ports)

It is purely a cosmetic preference, I prefer to put everyone on one line, keeps things short.