In message <FuIo8q.rJ@tac.nyc.ny.us>Christos Zoulas writes:

>In article <200005132053.NAA21977@champagne.dsg.stanford.edu>,
>Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

Christos,

my msincere thanks for the non-inflammatory response.


>Jonathan, I don't think that Itojun has ever stated that he does
>not want to fix these kinds of problems - in fact he has been very
>quick responding to each problem.

Yes. I agree. I have said so as much myself, several times.
Itojun *is* doing a really great job there. 
(Do I have ot say i every time?


[...]


>> Till now, I had assumed that "IPv6 integration" included making sure
>> that *non*-ipv6 systems also continued to work.  Itojun seems (to me)
>> to be saying that *he* thinks its not his job to do that.  But it is
>> very, very hard to tell.
>
>I disagree with that as I mentioned before.


Then we will have to agree to disagree.  In mutual good faith, I hope.
Just personally, this strikes me as the key point of disagreement. And
its even not over who does the work, but on the quality of support
NetBSD gives to traditional, non-IPv6, NetBSD users and installations.


>Jonathan, since you have personal interest in getting a non ipv6 system
>working, I suggest that you keep sending bug reports [preferrably as PR's
>instead of flames :-)] and we will fix them before 1.5 is released.

I will report what I find. But I simply dont have time to do that
task as effectiively as it needs to be done. I have papers to write, a
thesis to defend, and a day job.  I wish I could but it is not
realistic of me to say I can.


>It is definitely a good goal to be able to run all applications on a
>non ipv6 system.

I agree, only I'd s/good/vital/, for some part of the user base.  When
I think about this from a content-providers perspective, there are
excellent reasons to *not* be an early adopter of IPv6, but to stay
with solid IPv4 implementations.  I would hate to see NetBSD moving
backward from that perspective.



>Finally, yes the code is very new it has been tested only on specific
>configurations. It has not been stressed a lot and behaves non-intuitively
>in some cases. For example:
>
>	mv /etc/services{,.foo}
>	telnet machine.name
>
>and watch the error message.

>Let's calm down now and consider for a minute that Itojun is setting his
>own plan and goals on ipv6 integration. These are very well aligned so
>far with the NetBSD goals for the same. 

I am not so sure I agree on the last sentence
(up to now at least, when you say:

>I am pretty sure that testing on
>ipv4 only systems has not been given enough attention.

*thank you* That has been the point of contention here all along.


Heck, its only natural, when the people doing the integration work are
doing it beacuse they are pro-IPv6.  Some of them go as far as running
v6-only (v4-free) setups. I have no idea whether  Itojun does,
but I think you see on the cause for concern.


>But now that we
>know how things break, we are going to be more careful when making changes
>so that there will be less breakage. 

Wow.  Thats, all I was hoping to hear. From where I'm sitting it
sounds like a 180-degree switch.  "Thanks" is all I can say.


>Still though nobody is promising to
>do all the testing, but probably the importance of that will decrease as
>the system stabilizes more.

Understood.  ("of course", even ).

Myself, I would test more if I could. But most of the IPV4-only
systems I control are still running 1.4.x. The few that aren't only
have 3 or 4 entires in /etc/inetd.conf, so there's not much I *can*
test, because I'm not using it.


I think it really would help a *LOT* if there was, say, a list of
which subsystems (with subsystem defined by rc.d scripts) have been
hammered on on an IPv4-only systems, and which haven't.