Created attachment 154784 [details] svn diff for net-mgmt/tcptrack Well, I thought this was a pretty convenient tool. But noticed that: WWW has been long since abandoned, there were reported issues with it, as a result, it was slated for deletion, and there was no MAINTAINER. I'm here to say, none of those are any longer true. :) Reworked most all of the source, should no longer exhibit any issues. In short; Modifies PORTVERSION PORTREVISION MASTER_SITES MAINTAINER LICENSE WWW Removes files/* and this PR comes with an svn diff, and QA session LOG. Just to make the committer's job, not a job. :) Thanks!
Created attachment 154785 [details] QA session LOG for net-mgmt/tcptrack
Chris, few comments: - have you taken ownership of that project? You've changed MASTER_SITES to point to your personal page, but the current upstream doesnt seem to have any 1.4.3 version. If you dont own the project, then doing something like that is not possible. You should stick to the upstream or fork the project and create new port for your own fork. - if you're doing PORTVERSION bump, then PORTREVISION, if exists, should be removed instead of bumped.
(In reply to Bartek Rutkowski from comment #2) > Chris, few comments: > > - have you taken ownership of that project? You've changed MASTER_SITES to > point to your personal page, but the current upstream doesnt seem to have > any 1.4.3 version. If you dont own the project, then doing something like > that is not possible. You should stick to the upstream or fork the project > and create new port for your own fork. > > - if you're doing PORTVERSION bump, then PORTREVISION, if exists, should be > removed instead of bumped. Well, I thought I did the right thing; I fixed a bug in the source, and attempted to push the changes upstream. But the last known contact: tcptrack2 @ s.rhythm.cx isn't valid (s.rhythm.cx doesn't exist). So I simply bumped the version to reflect the changes. Given rhythm.cx, nor www.rhythm.cx exist. I opted to provide an informational web page for tcptrack. I see now that mi@ disregarded this pr(1) and pushed a fix for this some 8 wks. ago. So maybe this was all just a waste of time. :( Thank you very much, Bartek Rutkowski, for taking the time to look at this. --Chris
I have come across this situation many times where there is a delay in upstream acceptance of a patch, which could be for many reasons. In this case, I usually keep the MASTER_SITES as is, as they are the authority for the software, add the patch to the ${FILESDIR}, and bump the PORTREVISION. Assuming the patch is accepted at some point, the patch is removed and the PORTVERSION is bumped to match the new version which includes your merged patch from the upstream vendor. Thanks for your work!
revision 382040, makes this pr(1) redundant. Thanks to both Bartek Rutkowski, and jgh@FreeBSD.org for their valuable input, and attention to this. It was greatly appreciated. :) --Chris
Clean up after close