Bug 199419 - dns/firedns request MAINTAINER'ship, propose WWW
Summary: dns/firedns request MAINTAINER'ship, propose WWW
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-13 16:29 UTC by Chris Hutchinson
Modified: 2015-06-05 09:47 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (dean)


Attachments
svn diff for changes to dns/firedns (1.48 KB, patch)
2015-04-13 16:29 UTC, Chris Hutchinson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Hutchinson 2015-04-13 16:29:11 UTC
Created attachment 155547 [details]
svn diff for changes to dns/firedns

This is a proposal to the CURRENTLY listed MAINTAINER;

As I use this port, I recently responded to a notice that
the port was listed as BROKEN, because the source had gone
missing. Because I use this, and already had the source,
and time, I offered to host the source. Now that I host
the source, and have the time, I'd like to request MAINTAINER
for this port, as well. I mean no disrespect. I understand that
"Life Happens", and there is a myriad of things that can
get in the way. :)
The attached svn diff, also proposes changing the WWW
to one that relates to the application/port. Because the
one currently listed has no reference to this port/application.

Thank you for all your time, and consideration.

--Chris
Comment 1 Bartek Rutkowski freebsd_committer freebsd_triage 2015-06-05 09:47:55 UTC
I am closing and rejecting this PR, because the  dns/firedns port is not currently marked broken and it builds just fine. While this PR reached its maintainer's timeout, the change proposed is nothing more than change of the maintainer and the upstream location, while the new proposed maintainer has already a huge number of ports on his plate and the current upstream location works just fine.

I hope you understand the reasoning behind this decision and are aware that you still can propose updates to that port even when you're not its maintainer.