New port with maintainer ports@FreeBSD.org [was: Question about
pauls at utdallas.edu
Thu Jul 28 17:49:58 GMT 2005
--On Thursday, July 28, 2005 10:36:58 -0700 Frank Mayhar <frank at exit.com>
> 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 at 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
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 at utdallas.edu)
Adjunct Information Security Officer
University of Texas at Dallas
AVIEN Founding Member
More information about the freebsd-ports