On 01/22/15 10:49, K. Macy wrote:
Sigh, you still do not understand. It is your duty to identify all pieces
which break after your change. After that, we can argue whether each of
them is critical or not to allow the migration. But this must have been
done before the KPI change hit the tree.
Hi,
Are you saying that pieces of code that runs completely unlocked using
"volatile" as only synchronization mechanism is better than what I would
call a temporary and hopefully short TCP stack performance loss?
Hans - The project has long standing expectations about how changes
are made to core subsystems. When you hear "understand" your ego
intercedes - put that aside. I told you this first this afternoon and
others have repeated it several times. When you change a KPI,
consumers are updated at the same time - _period_. This protocol is
not up for debate. I'm glad that others have the presence of mind and
fortitude to insist on this. Your work is appreciated, but whether or
not you agree about this is not relevant.
We're all sorry if this upsets you but this is only a temporary
setback. Channelling this work through phabricator will go a long way
towards smoothing over the current friction. Think about the greater
goal here, not whether this is "done" now or in a week.
Hi Kip,
That is fine by me. I didn't know about the "protocol" you refer to
until now. I will revert my callout patch and hopefully without causing
any build issues and then we can have another round in the Phabricator
to iron out the TCP stack issues and possibly others. Sounds good.
Please give me some hours to ensure that the pullout doesn't cause any
build breakages.
Thank you!
--HPS
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
