Page MenuHomeFreeBSD

devel/py-gitpython: Update to 2.1.9
ClosedPublic

Authored by ygy on Mar 29 2018, 6:31 PM.

Details

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

PR: 227017
Approved by: woodsb02, che@bein.link (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

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

ygy created this revision.Mar 29 2018, 6:31 PM
ygy planned changes to this revision.Mar 29 2018, 6:31 PM

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 added a comment.Apr 1 2018, 6:28 PM

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 added a comment.Apr 3 2018, 1:41 PM

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

ygy updated this revision to Diff 42639.May 16 2018, 5:12 PM
ygy edited the summary of this revision. (Show Details)May 16 2018, 5:22 PM
ygy added a reviewer: woodsb02.
ygy edited the test plan for this revision. (Show Details)May 16 2018, 9:33 PM
mat added a comment.May 18 2018, 1:04 PM

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

ygy added a comment.May 23 2018, 3:55 AM
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 added a comment.May 23 2018, 2:35 PM
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 added a comment.May 24 2018, 5:25 PM
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!

ygy edited the summary of this revision. (Show Details)May 24 2018, 5:26 PM

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 added a comment.May 25 2018, 7:00 AM

Why bump dependant ports?

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 added a comment.Jun 7 2018, 3:03 PM

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

ygy edited the test plan for this revision. (Show Details)Jun 7 2018, 3:06 PM
ygy removed a subscriber: woodsb02.
woodsb02 accepted this revision.Jun 7 2018, 10:49 PM

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: che@bein.link (maintainer timeout)
Approved by: woodsb02 (ports)

Nice work Guangyuan!

This revision is now accepted and ready to land.Jun 7 2018, 10:49 PM
mat added a comment.Jun 8 2018, 8:37 AM

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: che@bein.link (maintainer timeout)
Approved by: woodsb02 (ports)

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

This revision was automatically updated to reflect the committed changes.