I am a Release Engineer on the Wikimedia Release-Engineering-Team.
That's odd :-/
Fri, Sep 21
Don't announce the stderr output
I was curious how much antivandalism was slowing things down so I disabled the rule and then checked transcripts on transactions that happened while the rule was disabled. It didn't seem to make a significant different in herald runtime. So although antivandalism does a couple of expensive sql queries, it appears that I've optimized that code sufficiently - the difference was only a couple of milliseconds at most.
@MGChecker: any custom fields which belong to one type would be lost when converting to another type. Converting a release task to any other type would completely break the release schedule and "task series" navigation (the prev / next links on each train release)... It would just be broken in multiple ways.
Ok I still haven't tested this in an environment similar to prod. I'll try installing and testing this patch in beta next.
Thu, Sep 20
@MGChecker: no I don't think so. Changing task types shouldn't be the norm and some changes would break things so it really shouldn't be on the normal task edit form.
I'll take a stab at calling echo 1 | mwscript eval.php in scap.
@MGChecker: The only way to manually change types is using the batch editor. There is also the possibility to build herald rules which either react to the type or set the type based on other criteria.
We are now at ~300ms
Tue, Sep 18
I don't think there is any way to solve this. There are just too many tasks to render within a reasonable time limit.
The SECURITY ISSUE task type can be created by using Form 48
Mon, Sep 17
Ok I got rid of "default": "default" from the custom field definition, now submitting a task shouldn't set the value at all
@chasemp I don't think so. Maybe if it didn't have a default value assigned?
Strange. I think that phab handles "select" lists in a weird way.
Should we raise the frequency of the restarts?
Wed, Sep 12
I went ahead and created https://phabricator.wikimedia.org/maniphest/task/edit/form/48/ which is an exact copy of form ♯3. ... it's a little annoying to maintain multiple forms but this will probably avoid some confusion.
@Legoktm: to avoid that we'd need to create a separate form which I think might be a better idea, I'm afraid people will be annoyed by the extra field. Note that it only shows up for some people (people who use the advanced form)
It's now mirroring to https://github.com/wikimedia/operations-software-keyholder/
@Legoktm: There was some concern about incompatibilities between the mbstring in php7 vs hhvm and an assertion that php7 would not build the localization cache correctly. I was never convinced that is actually the case. Unfortunately I can't seem to find where that discussion is logged, most of it was in IRC as far as I remember.
Mon, Sep 10
Unassigning but I'm still tracking this on my personal workboard (User-MModell)
@MGChecker: I don't see a problem with doing that.
Fri, Sep 7
Thu, Sep 6
Wed, Sep 5
@thcipriani no solution has been found yet for mirroring lfs.
Tue, Sep 4
Thanks, @EBernhardson. I will test it thoroughly before merging. I mainly wanted your eyes on it to be sure I wasn't doing something dumb which tests ok but has a bad impact on our elasticsearch nodes.
@faidon: The main thing in the diffusion repo is the debian packaging work that we did to get it in shape for publishing a deb.
Wed, Aug 29
I manually fixed all of the others that I'm aware of.
Tue, Aug 28
Should we be sure to log that canary checks were skipped?
See the comments on P7490 for details of the pattern I used with regex search & replace to format the output.
I used search/replace with the following regex to convert from mysql table formatted rows into the structured format seen above.