From owner-freebsd-ports@FreeBSD.ORG Thu Jul 28 17:49:58 2005 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ACBE16A420 for ; Thu, 28 Jul 2005 17:49:58 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from smtp1.utdallas.edu (smtp1.utdallas.edu [129.110.10.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE40343D5F for ; Thu, 28 Jul 2005 17:49:55 +0000 (GMT) (envelope-from pauls@utdallas.edu) Received: from utd59514.utdallas.edu (utd59514.utdallas.edu [129.110.3.28]) by smtp1.utdallas.edu (Postfix) with ESMTP id 05519388D81 for ; Thu, 28 Jul 2005 12:49:54 -0500 (CDT) Date: Thu, 28 Jul 2005 12:49:54 -0500 From: Paul Schmehl To: ports@freebsd.org Message-ID: In-Reply-To: <42E917BA.10406@exit.com> References: <42E81050.7090305@cs.tu-berlin.de> <66A226C3557B48ED535E3FED@utd59514.utdallas.edu> <20050727230523.GB54954@isis.sigpipe.cz> <20050728154248.GA943@zi025.glhnet.mhn.de> <20050728164111.GA66015@isis.sigpipe.cz> <42E917BA.10406@exit.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Re: New port with maintainer ports@FreeBSD.org [was: Question about maintainers] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 17:49:58 -0000 --On Thursday, July 28, 2005 10:36:58 -0700 Frank Mayhar wrote: > Roman Neuhauser wrote: >> The policy makers won, everybody else lost. > > Bullshit. Remember that you're getting all of this for _free_. You are > benefiting from the hard work of many others and yet you complain when > you are asked to contribute work yourself. > > In my case, I take it for granted that if I update a port there's a > damned good chance that I will be the stuckee for future problems with > that port. I guess I've worked as a software engineer for long enough > that I expect to exhibit a certain level of professionalism. This means > supporting my code, even if the system/subsystem/application in question > didn't originally have my name on it. > > I personally sympathize far more with the folks who are trying to > maintain this stuff than with those who whine that they shouldn't be > expected to actually support the stuff that they have submitted. In my > clearly NSH opinion, FreeBSD is better off without the > unmaintained/broken/obsolete ports. At least until someone feels > strongly enough to pick them up and maintain them. > > I _certainly_ think that a port submitted with a maintainer of > 'ports@freebsd.org' should hit the bit bucket immediately and never see > the light of day. If it's important enough to submit, it should be > important enough to maintain. > While I sympathize with and agree with much of what you're written, let's look at the practical application of your last paragraph. I decided to create new ports for a program called sguil. It's a network security monitoring program that offers great potential for usefulness to security professionals like myself. I had never created a port before, so I was starting from scratch. I quickly learned that, for the port to even build, I had to have a port for barnyard. So I created one. It took me while, but it's not part of the tree. I then discovered that, for the sguil port to work, I had to create a port for sancp. I did that too, and that's been accepted. Now I've finally created ports for the sensor and server portions of sguild, and I'm working on the client portion. If FreeBSD adopts the policy you suggest in your last paragraph, hat would me that I would *also* have to take over maintainence for the following ports: tcl, itcl, tk and iwidgets. Can you imagine for a moment how intimidated I would have been had I had to take on that additional challenge? I am not a programmer. I've taken classes in C++ and Java, and I write perl scripts fairly regularly. Trying to solve compile problems is, for me, time consuming and confusing. Furthermore, I have a fulltime job (and we're not talking 40 hours here either) just trying to keep a university secure - one of the most inhospitable places on the planet for security folks. If we adopted your suggestion, there would be no port for sguil, because I never would have taken it on. I would have given up. And that means there would also be no port for barnyard, and no port for sancp. Is that what you want? Paul Schmehl (pauls@utdallas.edu) Adjunct Information Security Officer University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/ir/security/