Created attachment 149679 [details] graphics/gdtclft UNBREAK, provide MASTER_SITES graphics/gdtclft FIXES provide MASTER_SITES (yes, I have, and can host the SRC) NOTES If desired, I would also be willing to become MAINTAINER (just saying) Please see the svn(1) diff(1) for details. --Chris
Maintainer CC'd
(In reply to Bugzilla Automation from comment #1) > Maintainer CC'd OK It's been over 30 days since I created this patch, and now this port is marked for deletion. I call MAINTAINER_TIMEOUT. Can someone please process this. My offer to maintain this port, still stands, if need be. Thank you for all your time, and consideration. --Chris
A commit references this bug: Author: antoine Date: Mon Jan 5 23:11:31 UTC 2015 New revision: 376371 URL: https://svnweb.freebsd.org/changeset/ports/376371 Log: - Provide a real MASTER_SITES - Pass maintainership to submitter PR: ports/195256 With hat: portmgr Changes: head/graphics/gdtclft/Makefile
Fixed, thanks.
(In reply to commit-hook from comment #3) > - Provide a real MASTER_SITES For the record, the submitted MASTER_SITES is not any more "real" than an empty string. Chris is not maintaining the gdtclft package -- merely hosting a copy of the old tarball. > - Pass maintainership to submitter A rather obvious abuse of power -- and a thinly veiled retaliation at me personally. Portmgr, please, consider expelling antoine@ from your ranks -- he has 32 ports of his own to maintain and is likely quite busy already. Thank you.
It has already been explained a couple of time, a port need a MASTER_SITE which is not distcache because distcache can be invalidated entirely at any moment resulting in the distfile being unfetchable. distcache (aka freebsd mirror for distfiles) is only there to provide the distfile when the master_site are temporary not reachable not as a main location to fetch the distfile. There is no abuse here
(In reply to Baptiste Daroussin from comment #6) > It has already been explained a couple of time, a port need a MASTER_SITE > which is not distcache It has already been STATED a number of times. And each time it was stated, it was countered by the fact, that distcache is more stable than an average master-site. This was the conclusion of our discussion on the matter, as far as I remember it. I'm summarizing it here, because portmgr@ archives aren't public. I also point out, that the "rule" you are putting forth above is not written anywhere -- portmgr@ is governing by fiat, making up rules as you go along. Maybe, that means, antoine@ does, indeed, fit the group better, than one might think... > There is no abuse here The abuse, in my opinion, is in the wanton reassignment of the port's mainterneship by antoine@ -- in obvious retaliation for my words today.
This is not a new policy. When I became a committer I was told that the policy was that FreeBSD.org did not want the resposibility to act as upstream for any software other than what we directly provided, e.g. what was under (then) CVS control. I became a committer quite a few years ago. If it is not documented in the Porter's Handbook, then that's a bug.
On Tue, Jan 06, 2015 at 02:31:31AM +0000, bapt@freebsd.org wrote: > > It has already been explained a couple of time, a port need a MASTER_SITE > > which is not distcache > > It has already been STATED a number of times. And each time it was stated, it > was countered by the fact, that distcache is more stable than an average > master-site. This was the conclusion of our discussion on the matter, as far as > I remember it. > To summarise previous discussions: distcache is exactly what it says in the name: a cache. It is not an authoritative site that can be used as a master site. If it is more stable than the average master site, it is exactly to have a fallback if a master site is temporarily unavailable, but it cannot in itself be a master site. It's as simple as that.