Repository navigation
Disable rules that failed automated ruleset test. - #1951
Conversation
Conflicts: src/chrome/content/rules/Valve.xml
Most or all of the former content has been moved straight to http://insights.dice.com/, which is not available over https.
They're in the process of moving it to https://disconnect.me/forum.
|
Having this parsed into a text list would be useful (X files are going to be disabled etc) |
Conflicts: src/chrome/content/rules/Debian.xml src/chrome/content/rules/Gentoo.xml
…disable-rulesets-june-2015-a
|
I've put a list of the affected files (744) here: https://gist.github.com/jsha/f25416034b4bd96db7da. BTW, if you spot common false-positive patterns in the checker output, please do file issues so we can improve the thing. This is a huge number of affected files, and I'd like to reduce the amount of work generated each time I run the checker. |
…to disable-rulesets-june-2015-a Conflicts: src/chrome/content/rules/Integrity.pt.xml
docs does too, but there's a little mixed content...
NXDomain, so cause test failure Ping #1951
|
What's the best way of fixing these up? Commits/PR to master? |
…isable-rulesets-june-2015-a Conflicts: src/chrome/content/rules/Google_App_Engine.xml
…to disable-rulesets-june-2015-a
Fix half a dozen rulesets
|
@reedy: Commits / PRs to master are great; Commits / PRs against this branch are also great. @2d1: Sorry that it feels hopeless. :-( I'd definitely like to find a better way to keep our rulesets in good working order without requiring lots of manual work. I tried this workflow (branch first, rather than push to master), because I felt like it would be less disruptive than the alternative. But I'd also be happy to start with a push to master as well. I also hear you about trying to fix as many of the generated issues myself before asking for help from the community. Honestly, I face a similar problem: fixing 744 rulesets by myself feels hopeless, and I feel the need to ask for help sooner rather than later. The web is a messy place, and the sites we include in our rulesets change quickly. It's hard to keep up. We can probably somewhat reduce the amount of work generated by ruleset testing if we make the checker remove individual target hosts rather than disable whole rules. This is tricky since a rule may have internal dependencies (i.e. only works if both sub1.example.com and sub2.example.com are both rewritten), but is probably safe enough for simple rules. Ticket filed: #1998. |
Conflicts: src/chrome/content/rules/GoogleMaps.xml src/chrome/content/rules/GoogleServices.xml
|
I've fixed up a bunch of the rulesets that contain names from the Alexa top 1k. Going to merge this now and make further improvements against master. |
|
Also to be clear, I'll leave at least one more week before rolling the next release, as you requested @2d1. |
Disable rules that failed automated ruleset test.
|
I wonder if/how many open issues this actually resolves too |
I ran the automated ruleset checker, and these are the rulesets that it disabled. I'd like to leave this pull request open for a week or so, so anyone who would like to fix a ruleset rather than see it disabled has that opportunity. /cc @2d1
Thanks,
Jacob