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