cvs commit: src/usr.bin Makefile src/usr.bin/doscmd AsyncIO.c
AsyncIO.h Makefile Makefile.dos PROBLEMS ParseBuffer.c README
README.booting_dos bios.c callback.c callback.h cmos.c com.h
config.c
Tim Robbins
tjr at freebsd.org
Wed Mar 24 23:03:55 PST 2004
On Wed, Mar 24, 2004 at 05:50:46PM -0500, John Baldwin wrote:
> On Wednesday 24 March 2004 05:35 pm, Julian Elischer wrote:
> > On Wed, 24 Mar 2004, Doug Barton wrote:
> > > On Wed, 24 Mar 2004, Julian Elischer wrote:
> > > > I think most people heard "tjr assented to waiting" as the end of the
> > > > discussion.
> > > >
> > > > remember emails can get re-orderred..
> > >
> > > This is where a good threaded mail reader helps. :) Seriously though,
> > > is there a strong, well-reasoned objection to the action by des, or can
> > > we let this one go? As I said, my opinion is biased, but I don't see any
> > > harm here on the tech side, nor do I see any bad faith on des' part.
> >
> > I don't think that, now that it's done, we should bring it back, but I
> > do think that he got a different impression about the conversation that
> > I got.
>
> Yes. I honestly don't care enough about doscmd(8) to want any changes from
> the current situation, but my reading of the thread was that the consensus
> was, if anything, to wait until 6.0. Upon re-reading the thread, I do see
> that while DES did say he would provide patches to do what he did, he never
> sent a mail saying 'Ok, here are the patches I'm going to commit on foo day'
> whereas Tim did sent out a RFC before doing actual action. Given the amount
> of pushback that Tim's request received, it seems to me it would have been
> good form to have at least posted something to the effect of 'Ok, I've got
> the patches do this now and am going to do so.'
I mainly agreed to wait because I was sick of arguing. I still firmly
believe that doscmd has no place in the base system of -current in 2004.
Tim
More information about the cvs-src
mailing list