Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jun 1996 18:28:43 +0200
From:      "Julian H. Stacey" <jhs@FreeBSD.org>
To:        Nate Williams <nate@sri.MT.net>
Cc:        current@FreeBSD.org
Subject:   Re: tcl -- what's going on here. 
Message-ID:  <199606231628.SAA17934@vector.jhs.no_domain>
In-Reply-To: Your message of "Fri, 21 Jun 1996 19:55:30 MDT." <199606220155.TAA15338@rocky.sri.MT.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Reference:
> From: Nate Williams <nate@sri.MT.net> 
> Subject: Re: tcl -- what's going on here. 
>
> > > 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.

I recall trying that route long ago, it has its problems:
not too many commiters read it, past cases of complaint of lack of
response, & something way back when required on-line ip I recall
I seem to recall worries about reply-to fields too,
(very important when accessing via dynamic allocation ISPs;
Still I'll give it another go for some of the bug fixes.


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

Some of these are ports wrappers to be committed to the FreeBSD ports tree,
it's not appropriate to send them to vendor.
Some (eg vi) have been submitted to `vendor' & current.


> Bugfixes get added when they are reviewed, new features get added *IF*
> the original vendor integrates them and/or they are critical to FreeBSD.

Extensions to FreeBSD src/ I've sent to current,


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

Thanks for looking Nate !

  BTW History of tree:	http://www.freebsd.org/~jhs/bsd/fixes/FreeBSD
  - started life as my private directory of fixes,
  - each time I had a new patch I posted it to current, with commentary,
  - realised much stuff fell between the cracks, & never got applied,
  - saved patches to my personal diff tree, to auto apply to virgin current,
    with ~jhs/bsd/fixes/customise
  - Added commentary to each new new patch
  - put tree up for public http
  - retrofit of commentary to old patches, completed ~2 days
    ago, but not uploaded to freefall before your mail arrived.
  - added automatically maintained hypertext clickable 
    src_index.html & will upload that too, when next on line,
    (while this mail is transferring).


> Complaining that you're code doesn't get integrated when you make it
> *hard* to find it, figure out what it does,

Sorry it was hard work to look at, so I've created a brand new 
	http://www.freebsd.org/~jhs/src_index.html
& all patches now have short `what for' descriptions


> and then the changes aren't even for code we maintain.

Many patches are for stuff we maintain,
but some are optional, like the vi + chimera + ghostview signal linking 
to achieve a sort of wysiwyg effect.

Julian
--
Julian H. Stacey	jhs@freebsd.org  	http://www.freebsd.org/~jhs/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606231628.SAA17934>