Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Jun 2020 18:20:44 +0200
From:      Josua Mayer <josua.mayer97@gmail.com>
To:        "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: routed && route6d removal proposal
Message-ID:  <eaee2d2f-aa90-cbb4-f3a2-315871c2681e@gmail.com>
In-Reply-To: <202006231444.05NEiaWV015841@gndrsh.dnsmgr.net>
References:  <202006231444.05NEiaWV015841@gndrsh.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Makes sense to me, thanks for explaining!
removal being a quite strong measure seems to need different reasons.

The alternative is to invert the problem and ask why component xyz
should stay in the base system - but I haven't heard anyone ask, so it
seems just fine ;)

Am 23.06.20 um 16:44 schrieb Rodney W. Grimes:
>> \o everybody,
>>
>> this is just a little sidenote from an outsider:
>> Isn't below remark a good reason to remove something from base?
>>
>> Like - would the bugfix have been available quicker if it had been in a
>> port? Would the reporter have actually tested the fix in that case?
> 
> It would of likely got even less attention as a port,
> and that would not of really effected the fact that Eugene
> moved on to another solution before the bug fix was completed,
> which is a common situation, people need there stuff to work,
> and they usually need it to work NOW, so when they hit a bug
> they find a solution, often without even submitting a bug
> report.
> 
> The fact that the patch was not back ported to RELENG_4
> so that Eugene could of tested it is also a factor here,
> and addressing those types of issues with a tool other
> than base removal is probably a more productive path
> forward.
> 
> Further the fact the code has been in use for 7 major
> versions since then makes use of that bug as a case for
> removal rather a far reach, IMHO.
> 
>>
>> Am 22.06.20 um 22:33 schrieb Eugene Grosbein:
>>> 23.06.2020 2:26, Rodney W. Grimes wrote:
>>>>> I'm not talking about RIPv2 inherent deficiencies.
>>>>> Our routed just glitches where quagga's ripd just works.
>>>>
>>>> And your PR# for reporting the bug is?
>>>
>>> Was. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=51927
>>> Never had a chance to verify if it was really fixed in HEAD because it was not for RELENG_4,
>>> so I moved to ripd. As you may remeber, RELENG_5 needed much time to become ready for production.
> 
> I till use a 5.x version of FreeBSD:
> 
> FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #1: Mon Jul  1 17:58:50 PDT 2019     root@pdx.rh.CN85.dnsmgr.net:/usr/src/sys/i386/compile/PDXMXPIE  i386
>  7:41AM  up 158 days,  8:16, 1 user, load averages: 0.03, 0.01, 0.00
> 
> It actually ended up with some very stable code.  5.4p8 is the
> end of line for much of my early personal work as the change to
> CAM broke most of that work.
> 
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eaee2d2f-aa90-cbb4-f3a2-315871c2681e>