From owner-svn-ports-all@FreeBSD.ORG Tue Dec 3 08:10:48 2013 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E266CBC; Tue, 3 Dec 2013 08:10:48 +0000 (UTC) Received: from huppa.tuxaco.net (tuxaco.net [IPv6:2001:41d0:1:66c1::1]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C392D1E67; Tue, 3 Dec 2013 08:10:47 +0000 (UTC) Received: by huppa.tuxaco.net (Postfix, from userid 1001) id 157232283B; Tue, 3 Dec 2013 09:14:32 +0100 (CET) Date: Tue, 3 Dec 2013 09:14:31 +0100 From: Philippe =?iso-8859-1?Q?Aud=E9oud?= To: marino@freebsd.org Subject: Re: svn commit: r335281 - in head: . audio audio/gnump3d Message-ID: <20131203081431.GB77731@tuxaco.net> References: <529C689B.9050902@marino.st> <20131202131244.GC71618@tuxaco.net> <529C8C1F.7050802@marino.st> <20131202134921.GD71618@tuxaco.net> <529C91F2.6020004@marino.st> <20131202145224.GH71618@tuxaco.net> <529CA16C.2060000@marino.st> <20131202184749.GC30485@lonesome.com> <20131203015955.GA55963@apnoea.adamw.org> <529D8DF3.7080906@marino.st> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <529D8DF3.7080906@marino.st> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-ports-head@freebsd.org, svn-ports-all@freebsd.org, ports-committers@freebsd.org, Adam Weinberger , Rene Ladan , Mark Linimon X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:10:48 -0000 On Tue, 03 Dec 2013, John Marino wrote: >=20 >=20 > On 12/3/2013 02:59, Adam Weinberger wrote: > >>> (2013/12/02 @ 1347 EST): Mark Linimon said, in 1.5K: << > >> My reasoning is that contributing to FreeBSD is sometimes > >> hard and thankless, and if someone just hears too much negative feedba= ck, > >> they may just find something else better to do. > >>> end of "Re: svn commit: r335281 - in head: . audio audio/gnump3d" fro= m Mark Linimon << > >=20 > > The style police (I'm looking at you, Alexey) should be allowed to fix > > commits for "correctness," and committers should be allowed to fix > > obvious mistakes for each other. > >=20 > > 1) You have the confidence that if you accidentally commit something > > with an obvious error, someone is likely to help you out and fix it for > > you. > >=20 > > 2) You don't have to sit there and stew when a commit accidentally > > breaks that port you love. Because let's face it, nobody wants to file a > > PR for ${PORT_OPTIONS:MODCS}. > >=20 > > 3) If everybody is empowered to fix obvious mistakes and style nits, you > > gain a consistent experience for the end-user, who we all theoretically > > work for. You know, rather than just having Alexey send you an email > > about the importance of not muting install commands, which everybody > > seems to ignore anyway. > >=20 > > 4) People need to un-knot their panties. Seriously. We're talking about > > "but *I* wanted to delete that port!" Someone did your work for you. > > Think about all the things you could do with the 30 seconds they just > > saved you. > >=20 > > But when faced with the choice between "let's all fix bugs and promote a > > consistent ports user experience" and "MINE!", we all know which one > > people will pick. >=20 >=20 > Except for the (unwarranted?) attack on Alexey, I'm pretty happy with > this post. >=20 > I want to address this statement from Mark, "While on portmgr I > maintained a deliberate bias in favor of existing maintainers. My > reasoning is that contributing to FreeBSD is sometimes hard and > thankless, and if someone just hears too much negative feedback, > they may just find something else better to do." >=20 > I think this bias has backfired. I also do not believe that a "regular" > maintainer, one that is responsible for 1-30 ports but no other > responsibilities, is not a creature that needs protecting. If they are > doing the job they volunteered to do, they aren't going to get "negative > feedback". If they have twisted knickers because somebody fixed an > obvious typo for them, then frankly they are too high-strung to be a > maintainer. >=20 > In many cases, no maintainer is better than an abusive maintainer, just > ask any user of vim. >=20 > Maintainers don't "own" the port, they are simply the primary > caretaker. Adam is completely correct that the main losers in this > "protection" of the maintainer are the ports users. >=20 > The other thing to consider is the trade-off. Mark decided to trade off > the rights of active maintainers in order to protect maintainers that > may be long inactive and unresponsive. This demotivates the active > volunteers! Nothing is free, every rule costs something. I don't know > if the effect on the other committers has been properly considered. >=20 > Please make it clear that MAINTAINER does not equal "owner" and > establish exactly when other can fix maintained ports. I don't think > it is hard. Is it broken on every platform? ok. Is it an obvious typo > causing a malfunction? ok. Does the proposed change alter the > original intent of the maintainer? no means "ok". >=20 > I think we want those maintainers that severely neglect their duties to > "find something else to do" and we want to instill that all ports are > community property and not individually owned. >=20 John, I agree with you but at a moment, it must be written somewhere and it must be clear for everyone (maintainer, committer and user). Today, it's not the case and I think that the whole issue is here. Yes, I over react because I'm bored that on a side some committers believe they can do what they want and on another side many PR came each day and have no respond. (we had PR opened on 2006 still active with no activity since many years!). We have to found a concession to allow reactivity and maintainers/committers's choice. Regards, --=20 Philippe Aud=E9oud > John