Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Enables NoCalibratorLinearSvmTest - #232

Closed
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7
Closed

Enables NoCalibratorLinearSvmTest#232
Anipik wants to merge 3 commits into
dotnet:masterfrom
Anipik:test7

Conversation

@Anipik

Copy link
Copy Markdown
Contributor

Related to #78

Test is enabled and corresponding Zbaseline files are added

cc @shauheen@Ivanidzo4ka@eerhardt @danmosemsft @codemzs

/// <summary>
///A test for PAV calibrators
///</summary>
[Fact(Skip = "Need CoreTLC specific baseline update")]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this one is still skipped?

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are getting enabled in #233

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I'm not sure I understand the situation here... I just came from #233, looked pretty straightforward, but why do we have a separate PR for this, which loooks like just a more incomplete version of #233? Did we mean to close this PR?


In reply to: 190633420 [](ancestors = 190633420)

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Anipik , so is what you're trying to do here, attempt to address the comment in #78 where @Ivanidzo4ka suggested a 471 file PR was hard to review, and asked to break these things into manageable chunks? If the goal is to make an easy-to-review set of PRs, I'm not sure a series of "nested" PRs is really helping, since, say, #233 has everything anyway, and we're made to understand #233 in the context of #232, but of course we can't actually do that unless we find the commit ids and run the diff ourselves.

Do I understand the situation with what you're trying to do with these PRs? If I do, I'm inclined to accept your PRs #233, #231, #228, and reject your #232, #230, #229, #227. (This of course assuming I've correctly interpreted how this ecosystem of PRs has been structured. Let me know if I haven't.) Sound good?

General thoughts: As near as I know there is no policy expressed anywhere against enabling multiple tests at once. I think the problem is that #78 was so large that it could not be effectively reviewed -- indeed the github web UI seemed to have no idea what to do with it, and Codeflow was similarly flummuxed. This latest series went in the opposite direction to the point that it is also hard to review. An intermediate stage between all-at-once and one-at-a-time would probably be more ideal. That is, #233 and #230 and #228, on their own seem like manageable easy-to-review chunks, so maybe we ought to structure the future PRs in that fashion.

Anyway, let me know.

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TomFinley I tried to enable one test at a time. Some of the existing tests are testing multiple models so i split them in the PR eg #229#232
I should have waited to create a PR for these new tests eg. #230 and #231 depends upon #229

#227#228#231#233 needs to merged. #230 would need to be rebased after that.

@TomFinleyTomFinleyMay 24, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all, or rephrase them as independent PRs. As near as I can see you will want three PRs. One for FastTree, one for AP, and one for I guess the calibration.

So let's think about what is actually happening here. These tests are, what, about three lines long each, and run independently of each other. The idea that the PRs for this somehow "need" to be nested does not make sense to me.

Let's go with this: goal should be to phrase PRs that are easy to review. Not too large. But large enough so I don't have to look a 7 separate PRs, each of which has perhaps two lines different between them and are all touching the same lines, just to figure out what is going on.

@AnipikAnipikMay 24, 2018

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Sorry to hear this. In that case please cancel them all. Rephrase them as independent PRs.

#227#228#231#233 are already independent PRs. Its Just the #230 that depends upon #231

@AnipikAnipik closed this May 24, 2018
@Anipik
Anipik deleted the test7 branch May 28, 2018 16:47
@ghostghost locked as resolved and limited conversation to collaborators Mar 30, 2022
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@Anipik@eerhardt@TomFinley