I've been around for a really long time now.
I thought about it yesterday. We should just bite the bullet and get git-lfs support for Gerrit. This is possible and is the best long-term solution. It keeps us from being tied into git-fat (unsupported and effectively forked by us), rsync, or archiva.
Thu, Aug 17
Thank you, that's what I sort of remembered from when we moved it, and it makes more sense now. I'm fine with leaving it in group0 to be honest.
Care to elaborate?
Added again, flushed caches. (Sorry for delay, was on vacation)
Disabling account creation is easy and can be done immediately and I think would be a decent stopgap for the current issue. Titleblacklist should be able to handle the editing issue, I think. Could probably add some new group if desired to simplify things?
Wed, Aug 16
Mon, Aug 7
Thu, Aug 3
I can confirm it's unused on mediawikiwiki. Stupid experiment: I pushed for installation and I pushed for its removal.
Wed, Aug 2
I'm curious about usage stats on this preference generally, at least across large.dblist.
Tue, Aug 1
More like just shy of 6%
chad@notsexy /a/ops/mediawiki-config/dblists (master)$ cat flaggedrevs.dblist | wc -l 53 chad@notsexy /a/ops/mediawiki-config/dblists (master)$ cat all.dblist | wc -l 909
Mon, Jul 31
Thu, Jul 27
Wed, Jul 26
If we want to do it in two batches as you're suggesting, we can amend my patch to do so. Let's follow up there
The idea I was noodling the other day was kind of a generic rsync service that "anything" (tbd how wide anything means) could hit. This would allow us to publish files to a single location for all git-fat users rather than having each service having to setup their own (and potentially set up multiple ones for various testing/staging environments as well).
Just wanting to clear up a little bit of FUD, since there seems to be this misconception that git-fat does not work in labs....
For checking in, yes without issue (that's all client side). However fetch/pull requires rsync access to fatten the blobs (internal term is hydrate).
We can also safely normalize the back compatible version to the new one 😊
Tue, Jul 25
I did not use that branch. I didn't even know it existed.
Mon, Jul 24
Reception123 is not missing from the database.
Fri, Jul 21
I don't want to backport this behavior. It's inconsistent, and the tags will be all wrong. The logic to build a particular release--they're repeatable--operates on major version numbers. Adding the minor version numbers for 27/28 special casing would complicate things needlessly. Please abandon those changes.
I was under the impression we couldn't do port-based LVS to the same domain. But I'm gladly willing to be wrong ☺️
Thu, Jul 20
Jul 20 2017
Thanks for all the work on this yesterday folks. We're resolved, so I'm guessing ok to move forward on wmf.10 for wikidatawiki?
Jul 19 2017
Well perhaps the issue is in the underlying JsonConfig that this is based on (which also has its share of issues filed....)
This really really needs fixing by someone who owns the extension. This has been going on for ~2 months now.
Okie dokie, misunderstood :)
Jul 18 2017
To be clear: it's not that this doesn't provide us some non-zero performance improvement. I just want to measure what kind of difference it makes in the world of HHVM. If it's needed still, fine. But if it's not, it's a weird legacy thing that I'd love to jettison (as it causes no end of headaches & confusion for people).
For CentralAuth? Eh, if you think it's necessary. I say just toss the fix over the wall and e-mail wikitech-l like usual. It's a pretty WMF-centric extension.
Count me in for Horizon over continuing to use Wikitech. Everything is moving to Horizon, it makes zero sense to have two places for this.
Is anything left for this?
Jul 15 2017
Jul 14 2017
- Make path configuration file for conftool configurable (also lets us disable the functionality)
- Fix line too long error
- Reuse existing node objects rather than constructing new ones
- Catch failures, and return the success/failure scenario to callers, it's on them to resolve as desired
@Ottomata Staff member w/ NDA? Jfdi
Jul 13 2017
1.30? We haven't even begun yet. Go ahead