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 ...

[Wilko Bulte]

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 at FreeBSD.org