Re: RFC: doscmd removal

On Sun, Mar 14, 2004 at 12:13:11PM +0200, Ruslan Ermilov wrote:
> > > 
> > > That might be and is the reason I asked for the reasoning behind it. One
> > > reason why keeping it in the tree is good, is because it help pick API
> > > changes that break it. Out in ports it might take a while to pick that
> > > up and then it will be the poor user's problem. :-/ Doscmd use parts of
> > > the kernel that isn't used by many other programs.
> > 
> > Port compile problems are typically picked up on bento within a week,
> > and often within 24 hours.
> > 
> No, the question was rather: how often the kernel gets updated on bento?

It's irrelevant. doscmd is not designed to replace a regression test
suite. Pulling in circumstantial properties when discussing core
properties is never a good idea. Especially when the circumstantial
properties have more perceived value than real value.

In other words: keeping doscmd in the source tree because we think
that it tests aspects of our ABI much better than when it's a port
is multi-dimensional bollocks. Frequency of ABI breakages would be
one aspect that could have some importance. However, if we break
our ABI frequently enough that having doscmd in the source tree is
a big win, then we're wasting time on trivialities and meaningless
arguments while leaving the key flaws and problems undealt with.

So, if we were to discuss that there's a value to have a select set
of ports built on a daily basis on our reference machines as a form
of sanity checking then I have no problem adding doscmd to that set.

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net