On 29 Nov 2012, at 07:02, Simon J. Gerraty wrote:
> On Wed, 28 Nov 2012 20:17:33 -0800, Alfred Perlstein writes:
>> I've seen what happens with large groups, it doesn't scale and basically
>> you wind up with the following type of reviewers:
>
> The issues you cite, are the result of taking a g
On 29 Nov 2012, at 04:17, Alfred Perlstein wrote:
> I've seen what happens with large groups, it doesn't scale and basically you
> wind up with the following type of reviewers:
I think we have to assume best intent here -- the goal of code review in
complex critical components is not to elimin
On 29.11.2012 01:35, Vijay Singh wrote:
a sign of poor prior testing and too much trust into the submitter of
the patch it wasn't an earth shattering event. Doesn't distract from
Andre, I am really quite disappointed to read this from you. The patch
I sent you was fine, and has been well teste
>On 11/28/12 7:49 PM, Garrett Cooper wrote:
>> I know it's sort of done in some groups [based on commit messages], but it w
>ould be nice to have it better formalized and socialized as well. Things like
Trying to get too formalized could be counter productive.
>> An extension of this code revie
On 11/28/12 7:49 PM, Garrett Cooper wrote:
On Nov 28, 2012, at 9:39 AM, Alfred Perlstein wrote:
On 11/28/12 12:01 AM, Andre Oppermann wrote:
On 28.11.2012 00:59, Robert N. M. Watson wrote:
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is im
On Nov 28, 2012, at 9:39 AM, Alfred Perlstein wrote:
> On 11/28/12 12:01 AM, Andre Oppermann wrote:
>> On 28.11.2012 00:59, Robert N. M. Watson wrote:
>>>
>>> On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
>>>
> Andre.. this breaks incoming connections. TCP is immediately reset
> a sign of poor prior testing and too much trust into the submitter of
> the patch it wasn't an earth shattering event. Doesn't distract from
Andre, I am really quite disappointed to read this from you. The patch
I sent you was fine, and has been well tested here. You modified it
and made the er
On 28 Nov 2012, at 19:32, Alfred Perlstein wrote:
> Do you think we need another TRB?
>
> It could be used to oust undesirable committers if needed.
Are we seriously having a discussion in which the merits of favouring
pre-commit code review for the things like TCP stack are in doubt? I'm not
Do you think we need another TRB?
It could be used to oust undesirable committers if needed.
Sent from my iPhone
On Nov 28, 2012, at 10:25 AM, "Robert N. M. Watson" wrote:
>
> On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
>
>> On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrot
On 28 Nov 2012, at 17:51, Gleb Smirnoff wrote:
> On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote:
> A> Personally I don't think we need any more anchors attached to people's
> A> feet when developing FreeBSD.
> A>
> A> Mistakes will happen, they will happen in head. Slowing do
Alfred,
On Wed, Nov 28, 2012 at 09:39:15AM -0800, Alfred Perlstein wrote:
A> Personally I don't think we need any more anchors attached to people's
A> feet when developing FreeBSD.
A>
A> Mistakes will happen, they will happen in head. Slowing down the
A> process to eliminate mistakes only wo
On Wed, 28 Nov 2012, Alfred Perlstein wrote:
Yes, and I didn't really expect you to answer (at least quickly) during
your FreeBSD hiatus. So it was seeking review by chance.
Alas I found and fixed the bug myself within 2.5hrs. While not optimal, a
sign of poor prior testing and too much tru
On 11/28/12 12:01 AM, Andre Oppermann wrote:
On 28.11.2012 00:59, Robert N. M. Watson wrote:
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately
reset and never even gets to the
listener process. You need to back out of fix this urge
On Wed, 28 Nov 2012, Andre Oppermann wrote:
Yes, and I didn't really expect you to answer (at least quickly) during your
FreeBSD hiatus. So it was seeking review by chance.
Alas I found and fixed the bug myself within 2.5hrs. While not optimal, a
sign of poor prior testing and too much trus
On 28.11.2012 00:59, Robert N. M. Watson wrote:
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and never
even gets to the
listener process. You need to back out of fix this urgently please.
I just found out and fixed it.
On 27 Nov 2012, at 23:29, Andre Oppermann wrote:
>> Andre.. this breaks incoming connections. TCP is immediately reset and
>> never even gets to the
>> listener process. You need to back out of fix this urgently please.
>
> I just found out and fixed it. Sorry for the bre
On 28.11.2012 00:05, Robert N. M. Watson wrote:
On 27 Nov 2012, at 22:54, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and never
even gets to the
listener process. You need to back out of fix this urgently please.
I just found out and fixed it.
On 27 Nov 2012, at 22:54, Andre Oppermann wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and
never even gets to the
listener process. You need to back out of fix this urgently please.
>>>
>>> I just found out and fixed it. Sorry for the breakage.
>>
On 27.11.2012 23:48, Robert Watson wrote:
On Tue, 27 Nov 2012, Andre Oppermann wrote:
On 27.11.2012 23:35, Peter Wemm wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and never
even gets to the
listener process. You need to back out of fix this urgently please.
I
On Tue, 27 Nov 2012, Andre Oppermann wrote:
On 27.11.2012 23:35, Peter Wemm wrote:
Andre.. this breaks incoming connections. TCP is immediately reset and
never even gets to the listener process. You need to back out of fix this
urgently please.
I just found out and fixed it. Sorry for th
On 27.11.2012 23:35, Peter Wemm wrote:
Andre.. this breaks incoming connections. TCP is immediately reset
and never even gets to the listener process. You need to back out of
fix this urgently please.
I just found out and fixed it. Sorry for the breakage.
--
Andre
On Tue, Nov 27, 2012 at
Andre.. this breaks incoming connections. TCP is immediately reset
and never even gets to the listener process. You need to back out of
fix this urgently please.
On Tue, Nov 27, 2012 at 12:04 PM, Andre Oppermann wrote:
> Author: andre
> Date: Tue Nov 27 20:04:52 2012
> New Revision: 243627
> UR
Author: andre
Date: Tue Nov 27 20:04:52 2012
New Revision: 243627
URL: http://svnweb.freebsd.org/changeset/base/243627
Log:
Fix a race on listen socket teardown where while draining the
accept queues a new socket/connection may be added to the queue
due to a race on the ACCEPT_LOCK.
The
23 matches
Mail list logo
