Date: Mon, 7 Feb 2011 00:18:01 +0100 (CET) From: Gerald Pfeifer <gerald@pfeifer.com> To: ports-committers@FreeBSD.org Cc: cvs-ports@FreeBSD.org Subject: Re: cvs commit: ports/graphics/metapixel Makefile distinfo Message-ID: <alpine.LNX.2.00.1102062342430.8943@gerinyyl> In-Reply-To: <1297028744.16814.33.camel@hood.oook.cz> References: <201101152257.p0FMvSTR058827@repoman.freebsd.org> <alpine.LNX.2.00.1101152358150.2354@gerinyyl.fvgr> <20110128212637.GB4687@lonesome.com> <alpine.LNX.2.00.1102022359120.14698@gerinyyl.fvgr> <1297028744.16814.33.camel@hood.oook.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Feb 2011, Pav Lucistnik wrote: >> 1 An infrastructure change is submitted. >> 2. portmgr (or other maintainers) review. >> 3. If the review is positive, a pointyhat run is kicked off and for >> every new failure >> - if the port is maintained, a PR is opened and assigned to the >> port maintainer; >> - if the port is unmaintained, it is marked BROKEN and DEPRECATED >> with a deprecation period of two months. >> 4. Unless testing has uncovered a real issue with the infrastructure >> change, it is committed after two months at the latest. > This would just mean that the change would stall for two months and > then the whole bullet 3 would have to be repeated. It also means that unmaintained ports that are problematic in some way get removed and thus out of the way relatively quickly. (Unmaintained ports that do not cause any troubles can happily stay, as can those having a maintainer.) > These changes need a focused, concentrated *short-time* effort to get > right. You can try to engage various maintainers but they're hardly ever > cooperative. In the big picture it's always more effective to do the > changes yourself than to micro-manage lot of uninvolved people. IMHO. My proposal is not about micro managing anything. It gives maintainers that need to take an action (and only those) a heads up, plus all users of unmaintained ports that need an action (and only those). Plus two months time for fixes to happen, maintainers to step down or up, other interested parties to commit fixes based on maintainer timeout,... And of course whoever submitted the infrastructure change triggering this will be happy to help! Also, I don't agree on effectiveness: Unless you are portmgr@, you cannot just change someone else's port, regardless of how small the change is. And touching ports you have never seen before and then hoping things are still allright is either extremely expensive in terms of learning and testing or risky. As for people being uninvolved, how would a maintainer of a port be not involved when there is a change to his/her port happening? In my experience, surprisingly often maintainers had actually hacked around the issue my infrastructure improvement addresses, so they were well aware of what was going on. (In my experience maintainers have been quite responsive, in fact I was truely impressed how 80% responded within days around the CPPFLAGS change.) Gerald
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1102062342430.8943>