svn commit: r292379 - in head/sys: netinet netinet6

[Steven Hartland]

Hey Gleb, sorry I didn't wait for your review, but I did ask around on what
the timeout for this would be and was informed 2 weeks and as it had been
over a month, with quite a bit of feedback from others in the area, all 
of which
had been addressed I thought that was reasonable.

A simple reply of "I do intend to review but don't have time yet so 
please wait"
I think would be useful in these types of situations, as I know 
everyone's busy
but its impossible to know what others are thinking.

Clearly the MTU think was just a silly mistake, which I backed out 
instantly so
lets not be to harsh on that one ;-)

With regards MAINTAINERS, is there any sort of automation which could alert
on this (pre-commit) hook maybe as I'm sure that would be helpful as a
reminder.

I would definitely like to understand more about your concerns and learn 
from
your knowledge in this area, so thanks for that offer, and while it does 
sound
unforgiving I totally understand where you're coming from.

Hopefully together we can bring this to a satisfactory conclusion as I 
would hate
for both carp and lagg to stay as broken, 2 years is long enough :D

     Regards
     Steve

On 17/12/2015 00:38, Gleb Smirnoff wrote:
>    Steven,
>
>    I'm sorry that wasn't able to review D4111 in time, but I have
> very strong concerns against r292275. And r292379 doesn't
> improve situation. I am asking you to back out both patches,
> and then we can get together back to the problem. The 156226
> bug was sitting for 2 years in the bugzilla for a reason. It
> is a not "low hanging fruit" like koobs@ says.
>
> I'm sorry if I sound unforgiving, but you got a very bad commit
> record in this area. You committed r290403 to ip_carp.c which
> "added MTU support to carp interfaces", and that was after 4 YEARS
> of carp(4) being not an interface. So, I assume you doesn't
> have a good understanding of the current state of the stack,
> direction it is developed and things that can be done and
> can not (including DELAY() in callout(9).
>
> Note, that the MAINTAINERS file still lists me for ip_carp.c,
> and you didn't wait for my review. yet another reason to ask
> for backout.
>
> I understand that you got a product at work that needs to
> have problem fixed. I'm glad that you got a patch that works
> it around. But that doesn't mean the patch should immeditely
> be dumped in head with a threat of soon MFC.
>