From owner-cvs-all@FreeBSD.ORG Wed Mar 19 13:21:22 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 755791065671; Wed, 19 Mar 2008 13:21:22 +0000 (UTC) Date: Wed, 19 Mar 2008 13:21:22 +0000 From: Alexey Dokuchaev To: Pav Lucistnik Message-ID: <20080319132122.GB90943@FreeBSD.org> References: <200803180100.m2I10QTD070047@repoman.freebsd.org> <20080318193855.0439b197.stas@FreeBSD.org> <20080318181546.GA10903@FreeBSD.org> <1205917353.76695.0.camel@pav.hide.vol.cz> <20080319091859.GA56200@FreeBSD.org> <1205921932.76695.14.camel@pav.hide.vol.cz> <20080319112314.GA76554@FreeBSD.org> <1205929480.76695.36.camel@pav.hide.vol.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1205929480.76695.36.camel@pav.hide.vol.cz> User-Agent: Mutt/1.4.2.1i Cc: Stanislav Sedov , cvs-ports@FreeBSD.org, ports-committers@FreeBSD.org, cvs-all@FreeBSD.org, Pietro Cerutti Subject: Re: cvs commit: ports/java/eclipseme Makefile distinfo pkg-plist X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 13:21:22 -0000 On Wed, Mar 19, 2008 at 01:24:40PM +0100, Pav Lucistnik wrote: > Alexey Dokuchaev p??e v st 19. 03. 2008 v 11:23 +0000: > > > I wonder what's wrong with coherent and sane policies? I don't expect > > it would be hard to come to agreement about muting/not muting > > mkdir's/installation statements. These things are not of the type people > > usually feel strongly about. > > I like the high level of creative freedom the maintainer is entitled to. > Rigid policies on unimportant details of style will kill the fun. I've seen this reasoning before; IMHO it is more of speculation though. Policies can be, and are, different. Including ones that have impact on one's "creative freedom", and ones that don't. When people create or improve on a port, no one tells them how to do what they intend, when they do it correctly and sanely. I have also observed what people who know our bpm & friends well enough are less prone to errors and non-optimal decisions and code. It is also true that it takes time to know about every possible implication of different way of doing things; it takes time to get wisdom about compiler flags, right file permissions, difference between port vs. package installation, := vs. = (yes, I'm about BR_DEPS here), various upgrade-path scenarios, etc. Even trivial things, like starting COMMENT with "Foo is ..." are not obvious up front. There are many ways of doing things in a nice, clean manner. Yet there're more ways to come up with something cumbersome and obscure. When I say we need policy, I think of carefully selected and documented things to avoid and be careful with, not about strict recipes for doing this thing or that. I'm not talking about patching files vs. inplace editing, or about amount of whitespace in OPTIONS items. I'm talking about that there's certainly a grow-space in our culture and taste for something that can be treated as a state of art, e.g. our ports. To me, producing something *good* is more fun than just producing something. This is important because vast number of maintainers are not committers, ergo they might not be of high level of qualification a committer is required to have. Yet I see a tendency among us to overvalue the tinderbox as a criteria whether new port or proposed change can go into the tree or not. This is obviously not enough. By going with "it compiles, installs/deinstalls, let's ship it" attitude we're not setting a higher standard for people who are considering making their first port or adopting existing one. And we probably should. Dixi. ./danfe