svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

Randy Stewart randall at lakerest.net
Thu Jan 22 05:19:33 UTC 2015


All:

I have finally pulled my head out of the sands of TLS and 
had some time to look at this interesting long thread. I agree
with Warner and Adrian on this.. Lets back it out
and then in a branch chew this over piece by piece..

R
> On Jan 21, 2015, at 7:10 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> 
> On 21 January 2015 at 16:07, K. Macy <kmacy at freebsd.org> wrote:
>>>> HPS: Your change failed to meet these guidelines. Some of us are upset
>>>> because these guidelines are fairly fundamental for the on-going
>>>> viability of FreeBSD. Due to linguistic / time zone / cultural
>>>> differences these expectations have not been adequately communicated
>>>> to you. You are not in the USB sandbox where others need for your
>>>> support outweighs the inconvenience of random breakage.
>>>> 
>>>> It sounds like you are making progress towards updating the concerns
>>>> that have been voiced. If kib's observations are in fact comprehensive
>>>> then adding a callout_init_cpu function and updating all clients so
>>>> that their callouts continue to be scheduled on a CPU other than the
>>>> BSP will suffice and we can all move on.
>>> 
>>> Is there some reason that we can’t back things out, break things down into
>>> smaller pieces and have everything pass through phabric with a wide
>>> ranging review? Given the fundamental nature of these changes, they
>>> really need better review and doing it after the fact seems to be to be
>>> too risky. I’m not debating that this “fixes” some issues, but given the
>>> performance regression, it sure seems like we may need a different
>>> solution to be implemented and hashing that out in a branch might be
>>> the best approach.
>> 
>> Thank you. A more incremental approach would be appreciated by many of
>> us. To avoid the bystander effect we can permit explicit timeouts for
>> review-to-commit (72 hours?) so that we don't collectively end up
>> sandbagging him.
> 
> I'm +1 for this.
> 
> 
> 
> -a
> 
> 

-----
Randall Stewart
randall at lakerest.net






More information about the svn-src-head mailing list