Re: [Wikitech-l] My Phabricator account has been disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/09/2018 04:55 AM, Aryeh Gregor wrote: > The main problem here that needs to be solved is communicating > what the problem was in a manner that is clear to the parties whom > the CoC committee seeks to deter. A one-week ban is not going to > help anything if the object of the ban doesn't understand what > about his behavior elicited the ban. This. Blocks should be preventative, not punitive[1]. If after a week is up, and the subject doesn't understand the problematic behavior, or has no intentions of fixing their behavior, then we're just going to find ourselves in another wikitech-l thread about the same issues a few months later. And I'd rather we not. [1] https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Blocks_should_be _preventative - -- Legoktm -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAltvy9kACgkQUvyOe+23 /KKMrBAAjpe/E0Pk91hK+jP6/OFNGhX5g+Po0q63yjyor2qKAxJk2EZJSad4hRK8 jK/jv223dgqmHYmmX3Sf4ZMmu42N8kL54eKvFraGyjNBCdNlINxf+KTO/KLJ+bO1 mmjZlua/fWaoYoeIv/dywJW5u4p2xA9H1hP/6RychlX+n6P+6R2dLK+JZSHts3Bg 6HWSFnl6OQZ2DrxuSiUoYkRj/syouGUEw0KWH3h/ScBpeWmhgd+PRS5wN0MVCsgW h5rLMcJ1PUN/uQ6g8qW0f11LYxjWvfQY8uPXbj1cP6jJHnpFtgtUHWzsfWhWKpyY /PT7i5gPMzibn6GiDCNm6bOMokWAC+b9aezeuYq8HhPOh10qo2tJwLJ0qPfixodX uJQeKDklb3rJVUl+M0dvN5xp54nfGjLxGd69fCAIuLBM4pKzAp2vyVKigbikTCcq 5nxpSn3sEg+/u8i/1X0mTI4z0IpfoZIwFGXJ8kZb3NWbJkW8ihI+mq/ZXwFc8RP4 TVtZOLzpRxeJoIppnf+108RutXAIV973kXGRIrpf9RKvq3yjykZzjUxoDYTaTZVv FszYuxiWmIo91EfrXffJ+nmfPMza2O3awJo6Yy6ffh5KSGjFG0iJGiNh1RdN3R3R gspxXaIBvyNj0AlqvVKJM72EUPZdxp+SiQpUecj2ssPya91AeyU= =WKSj -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] My Phabricator account has been disabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, On 08/08/2018 03:08 AM, Amir Ladsgroup wrote: > I disabled the account and now I disabled it again. It's part of a > CoC ban. We sent the user an email using the "Email to user" > functionality from mediawiki.org the moment I enforced the ban. > > We rather not to discuss details of cases publicly but I feel this > clarification is very much needed. Regardless of whether the amendment of a public disclosure of stuff passes, there needs to be a way for Phabricator administrators to know not to reverse a disabling. The disable log is fairly useless, it just shows the actor and the target - it doesn't even say whether the account was enabled or disabled. Had I been online when MZMcBride sent his email, I probably would have acted similarly to Mukunda, assuming it was an accident of some sort, and re-enabled the account. - -- Legoktm -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAltvyZkACgkQUvyOe+23 /KJyEw/8CJcTROrxHyC9X7dcMC1vVOCVwa3p6aU2TBVgW9hx7ePDaluG4IiAZv+Z pLIR9mCQcsrIPDt0KiekAwZG2V4p57H22IQkpBFkqY3erO3wSwNIaar+t+Wa1jgI 0tCVe8HAGIknxOoN+MlMj7WG+L43PXBJhP1JObahE17cKDv+aZh3rOkHSBNS3XKy F20sN1Wn2MoA3KveKyVsu2FSwaeWLvqzC31wDcr3zr8OrDj4xjf8dwltDVBBVlDQ Hhq5XPiGNK50sejOpS+10VgK/yEWQ+0Bl0eiVuAI/mG4koCktVzlUbBtSRKtdSV/ CfOVOfBc0AJm8lCnlQJ3kQRssbPS8hv77JO7oIv2oneS0g/63uG/gc34a084MwBL Fv2LVA/eYShoG/cnajkvT6MMosSc+G79SitCjXvuzvjE1NDjS1ne6IcNhJ9tQ2Hc 93zEFkvc+0iG0xWyl8BFFmW1EElEark4sbdvRxRmfekZJ1dSecuUcV5ibMuLtDkx p+ghpPveYqb19cbOaTX40oEqTPAx8szNcRDFlkzQrYBKO1KsgfnjiVC1OGTwGNOH g/zUvfDW2FsYmaDsYrToX0szjB6bUldtpQx1AmnO9cHBLPLCQuBiVl1tAYjMHOwj 7qcY3Xy46GHRQffEVlr7d5hel764Vtwa36iwtpDlK+3JbkDe1J0= =+ZbW -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] ForkableMaintenance: thoughts and help with tests/code coverage
Hey all!
While working on some maintenance scripts for TimedMediaHandler I've been
trying to make it easier to do scripts that use multiple parallel processes
to run through a large input set faster.
My proposal is a ForkableMaintenance class, with an underlying
QueueingForkController which is a refactoring of the
OrderedStreamingForkController used by (at least) some CirrusSearch
maintenance scripts.
Patch in progress:
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/451099/
The expected use case is a relatively long loop of reading input data
interleaved with running CPU-intensive or DB-intensive jobs, where the
individual jobs are independent and order of input is not strongly coupled.
(Ordering of _running_ of items on the child processes is not guaranteed,
but the order of result processing is guaranteed to be in the same order as
input, making output across runs predictable for idempotent processing.)
A simple ForkableMaintenance script might look like:
class Foo extends ForkableMaintenance {
// Handle any input on the parent thread, and
// pass any data as JSON-serializable form into
// the queue() method, where it gets funneled into
// a child process.
public function loop() {
for ( $i = 0; $i < 1000; $i++) {
$this->queue( $i );
}
}
// On the child process, receives the queued value
// via JSON encode/decode. Here it's a number.
public function work( $count ) {
return str_repeat( '*', $count );
}
// On the parent thread, receives the work() return value
// via JSON encode/decode. Here it's a string.
public function result( $data ) {
$this->output( $data . "\n" );
}
}
Because data is serialized as JSON and sent over a pipe, you can't send
live objects like Titles or Pages or Files, but you can send arrays or
associative arrays with fairly complex data.
There is a little per-job overhead and multiple threads can cause more
contention on the database server etc, but it scales well on the subtitle
format conversion script I'm testing with, which is a little DB loading and
some CPU work. On an 8-core/16-thread test server:
threads runtime (s) speedup
0 320 n/a
1 324 0.987654321
2 183 1.74863388
4 105 3.047619048
8 66 4.848484848
16 58 5.517241379
I've added a phpunit test case for OrderedStreamingForkController to make
sure I don't regress something used by other teams, but noticed a couple
problems with using this fork stuff in the test runners.
First, doing pcntl_fork() inside a phpunit test case has some potential
side effects, since there's a lot of tear-down work done in destructors
even if you call exit() after processing completes. As a workaround, when
I'm having the child procs send a SIGKILL to themselves to terminate
immediately without running test-case destructors.
Second, probably related to that I'm seeing a failure in the code coverage
calculations -- it's seeing some increased coverage on the parent process
at least but seems to think it's returning a non-zero exit code somewhere,
which marks the whole operation as a failure:
https://integration.wikimedia.org/ci/job/mediawiki-phpunit-coverage-patch-docker/460/console
Worst case, can probably exclude these from some automated tests but that
always seems like a bad idea. :D
If anybody else is using, or thinking about using, ForkController and its
friends and wants to help polish this up, give a shout!
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] My Phabricator account has been disabled
>After several negative examples discussed in the last few months on this list,* this action conclusively proves in my eyes the failure of the Code of conduct to be a positive force for our community, at least so far >and in the present conditions. The CoC will prioritize the safety of the minority over the comfort of the majority. It might not be perfect but it is sure already working well to echo and document the concerns of many in the community that really do not feel comfortable to reply to a thread in this e-mail list. Or phabricator. Or a talk page. Reports are confidential and would continue to be so to make sure everyone feels safe to report *any* incident of *any* severity. On this specific case discussing whether profanity is OK or not is just a distraction as there is a long history of hostility and harsh criticism. The way the bug was closed might be incorrect (I personally as an engineer agree that closing it shows little understanding of how technical teams do track bugs in phab, some improvements are in order here for sure) but the harsh interaction is just one out of many that have been out of line for while. Thanks, Nuria On Wed, Aug 8, 2018 at 8:42 PM, Federico Leva (Nemo) wrote: > Thanks Amir and MZMcBride for disclosing the action. > > A volunteer has been punished for speaking up in defense of fellow > volunteer and paid contributors, whose contribution was being sidelined and > suffocated by people "in charge" of the specific space, i.e. the people > they were doing their best to help. > > The message which was sanctioned was even of an especially thoughtful > kind, in my opinion, because it didn't attempt to submerge the other users > with walls of text, politically correct tirades or otherwise charged > statements. It was merely a heartfelt interjection to help people stop, > reconsider their actions and self-improve without the need of lectures. Was > this peculiar effort at constructive facilitation considered? If not, what > alternatives or constructive suggestions were provided? > > After several negative examples discussed in the last few months on this > list,* this action conclusively proves in my eyes the failure of the Code > of conduct to be a positive force for our community, at least sso far and > in the present conditions. > > The committee needs to immediately resign or be disbanded, and be reformed > on a more solid basis. > > Federico > > (*) And not a single disclosed positive action, as far as I know. But it > might have been lost due to the lack of a transparency report. If one was > released or is upcoming, sorry; I'll revise my conclusions accordingly. > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
