Date: Fri, 21 Jun 1996 19:55:30 -0600 From: Nate Williams <nate@sri.MT.net> To: "Julian H. Stacey" <jhs@FreeBSD.org> Cc: Nate Williams <nate@sri.MT.net>, current@FreeBSD.org Subject: Re: tcl -- what's going on here. Message-ID: <199606220155.TAA15338@rocky.sri.MT.net> In-Reply-To: <199606211810.UAA07938@vector.jhs.no_domain> References: <199606202200.QAA11554@rocky.sri.MT.net> <199606211810.UAA07938@vector.jhs.no_domain>
next in thread | previous in thread | raw e-mail | index | archive | help
> > If you want something done, *DO IT YOURSELF*. > > Writing code is _easy_, getting it _committed_ is the hard bit, nothing > I can do about that, just keep posting, then give up, & file each bit > in parallel src & ports trees, ( I've recently made these trees of patches > & extra bits available under http://www.freebsd.org/~jhs/src/ ). I'm glad you sent them via proper channels (NOT!). I've not seem them on bugs or via send-pr. > EG: ports/mail/exmh: waiting 6 months, there were some imperfect bits, > since fixed, version upgraded, still waiting... > > EG vi + chimera + ghostview diffs to implement a Wysiwig sort of thing, > they add extra functionality, they're small, they do no harm ... But all of these are code we get from outside vendors. If you want it added to them, get the vendor to add it first. Bugfixes get added when they are reviewed, new features get added *IF* the original vendor integrates them and/or they are critical to FreeBSD. > Coding is easy, getting things committed is far far harder. Especially given that it's more difficult to figure out what you're attempting to do. I just looked through your 'submissions' and it's not obvious *what* you're fixing, and if they are indeed fixes. Complaining that you're code doesn't get integrated when you make it *hard* to find it, figure out what it does, and then the changes aren't even for code we maintain. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606220155.TAA15338>