From owner-cvs-all@FreeBSD.ORG Wed Jun 4 20:29:45 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E680106566C; Wed, 4 Jun 2008 20:29:45 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id A0F388FC12; Wed, 4 Jun 2008 20:29:44 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [82.95.250.254]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id m54KTeLo004335; Wed, 4 Jun 2008 22:29:40 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.14.2/8.13.3) with ESMTP id m54KTemJ032341; Wed, 4 Jun 2008 22:29:40 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.14.2/8.14.2/Submit) id m54KTeaI032340; Wed, 4 Jun 2008 22:29:40 +0200 (CEST) (envelope-from wb) Date: Wed, 4 Jun 2008 22:29:39 +0200 From: Wilko Bulte To: Coleman Kane Message-ID: <20080604202939.GB32282@freebie.xs4all.nl> References: <48405C4B.3050603@FreeBSD.org> <1212179252.1967.1.camel@localhost> <20080604041815.GA84027@FreeBSD.org> <20080604043955.GA38627@troutmask.apl.washington.edu> <20080604063631.GA28351@freebie.xs4all.nl> <20080604150013.GA44358@troutmask.apl.washington.edu> <20080604191339.GA31570@freebie.xs4all.nl> <20080604192955.GA46284@troutmask.apl.washington.edu> <1212608575.15220.109.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1212608575.15220.109.camel@localhost> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Maxim Sobolev , Alexey Dokuchaev , src-committers@FreeBSD.org, Florent Thoumie , cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Steve Kargl Subject: Re: cvs commit: src/usr.sbin/pkg_install/add main.c pkg_add.1 src/usr.sbin/pkg_install/create main.c pkg_create.1 src/usr.sbin/pkg_install/delete main.c pkg_delete.1 src/usr.sbin/pkg_install/info main.c pkg_info.1 ... 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, 04 Jun 2008 20:29:45 -0000 Quoting Coleman Kane, who wrote on Wed, Jun 04, 2008 at 03:42:55PM -0400 .. > On Wed, 2008-06-04 at 12:29 -0700, Steve Kargl wrote: > > On Wed, Jun 04, 2008 at 09:13:39PM +0200, Wilko Bulte wrote: > > > Quoting Steve Kargl, who wrote on Wed, Jun 04, 2008 at 08:00:13AM -0700 .. > > > > On Wed, Jun 04, 2008 at 08:36:31AM +0200, Wilko Bulte wrote: > > > > > Quoting Steve Kargl, who wrote on Tue, Jun 03, 2008 at 09:39:55PM -0700 .. > > > > > > > > > > > > I personally believe that commit should be backed out and core > > > > > > should establish a policy against adding long options to BSD > > > > > > > > > > Gimme a break.. > > > > > > > > > > > > > Note I wrote "I personally believe". You don't have to agree > > > > with me. > > > > > > Well I indeed do not agree. Aren't the developers old enough > > > to make this kind of judgement call themselves, without all sorts of written > > > policies? > > > > Apparently, not. See the recent commit to pkg_create. > > > > I believe the comment was meant to convey that this sort of call should > be left to the person doing the work. Making up a book of obtuse policy > rules such as this, for purposes that aren't very concrete, doesn't seem Well Coleman, I do apologise for being slightly terse but indeed, that is exactly what I meant to say. I prefer common sense over a library of rule books any day. > to serve anybody well. The whole reason long options exist is because a > significant group of users actually find them helpful. It's really > counterproductive (not to mention narrow-minded) to dismiss that. > > I support the efforts of flz on this one, he took the time to do the > work and wanted to commit it. I actually find your above comment to be > pretty offensive, and dismissive of the hard word that flz has done. > > > > > > > I would think they all are! > > > > > > > Where do we stop? Should we add long options to all > > /usr/bin utilities? Why stop at /usr/bin, let's add > > long options to /usr/sbin, /bin, /sbin, /rescue, etc. > > > > I'm sure if someone has some "add long options to /bin/cp, etc..." > patches, we can surely discuss them on this list as adults and respect > the decision to add new features without deprecating any existing > features, even if we won't be making use of those new features. Amen. > -- > Coleman Kane --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org