sap_general_preconfigure: Role fails if DNS domain is not set on the managed node (lsr/sap-preconfigure issue #98)

This is a copy of https://github.com/linux-system-roles/sap-preconfigure/issues/98, reported by alexxa:
This is a ToDo note to check on workaround for the issue when the roles fails if DNS domain is not set on the managed node, and a user needs to specify it and rerun the play.
Intentionally, Ansible doesn't allow to prompt users on tasks level, but it seems it's possible to do in a pre-task using pause + prompt + set_facts + when (dns is missing). Another solution may be an action plugin to ask the user to input a variable (or interrupt the play).

Copy of https://github.com/linux-system-roles/sap-preconfigure/issues/98#issuecomment-713413729:
The RHEL System Roles for SAP document for version 2 will contain the following text:
In case there is no DNS domain set on the managed node, which is typically the case on cloud systems, the role sap-preconfigure will fail in task "Verify that the DNS domain is set". To avoid this, set variable sap_domain in file /usr/share/ansible/roles/sap-preconfigure/defaults/main.yml or run the ansible-playbook command with line parameter
-e "sap_domain=example.com" (with the domain name being example.com in this case - please replace it by your domain name).
Is that OK for you?

Copy of https://github.com/linux-system-roles/sap-preconfigure/issues/98#issuecomment-713426926 (comment by alexxa:
Yes, sure. It's good to publish it as a workaround. However, I would recommend a fix for the next version as per initial comment.


User guide doesn't cover unjoin

User guide doesn't cover unjoin
fixes #638

/lgtm

/ok-to-test
/lgtm
/approve


Selectable Tiles is not working correctly on Linux OS

example of selectable tiles is not working on Linux VM, tested on RHEL7, Cent 6

@maple10001 can you test with the latest grommet and provide more details about the browser you're using?  A CodePen would also be valuable.

Closing for now.


Training for rapid on-boarding

In the most optimistic scenario, there is a great need for treatment providers, including operators of systems,  dealing with patients, treating patients, triage, etc.
what is needed is an education system:

at least part of the system should be online
supports self-paced learning, videos, tests and step-by-step tutorials.
linked with actual hands-on experience and workshop.
differentially available to medical personnel and beginners (e.g., students, soldiers)
include a simple process of extracting education material form medical personnel, who are otherwise needed at the front line
include a continuing education component whereby such trainees can be updated regarding critical change sin what they learned
linked with the actual work being done by people trained using the system

in general, what is needed are idiot-proof methods, protocols and devices


Update default Go Container to 1.18.3

Brand new build is still on Go 1.18 when using the 1-bullseye VARIANT.

What environment are you using? Is this happening Codespaces/Remote-Containers?
Also, are you talking about the go definition, the codespace image, or something else we publish that includes go?

Codespaces in the browser, if I setup new devcontainer files via the built in commands (ctrl-shift-p), choose Go as the language (no other options chosen), it will build with 1.18.

Apologies for not following up - this should be all updated now 🚀.
Note that in Codespaces we cache certain images (like this one).  It sometimes takes a couple days for us to rebuild that cache, so if you get a codespace with an older version, open the command palette in vscode and > Codespaces: Rebuild Container to get the latest image pulled.  Thanks!

Thanks!  And yes, I do rebuild often to get updates, but this one was stuck at 1.18. Is there a better process to get version updates or should I create an issue like this to get an update pushed out?

Generally we should be quicker to jump on breakfix updates like this, so I appreciate the issue - feel free to create an issue if we lag behind again :)
We provide all the source code for our images (go is here - https://github.com/microsoft/vscode-dev-containers/blob/main/containers/go/.devcontainer/base.Dockerfile), so if you found yourself immediately always needing the cutting edge, you could use our Dockerfile directly (but hopefully we're quick enough in the future that isn't necessary)

So just FYI, I rebuilt a project that uses the default Go configuration files and it is now 1.18.3. 👍  But the default Codespaces container (the kitchen sink one) is still 1.18 after a rebuild.

Good to know, I'll double check that.  They use the same script to install, so I would have expected them to both be updated

Not to be annoying, but could this get bumped to 1.18.4 now? It was released on July 12th.

Will do, thanks for the ping!

published! @treeder (Again, the codespaces cache will take a few days to update, but a rebuild will always pull the latest!)


Casting to (string) relies on PHP precision setting to be between 3 and 8 to work as expected

I noticed in the constructor for Number you do a (string) $number.
https://github.com/mathiasverraes/money/blob/nextrelease/src/Number.php#L25
We had some problems doing this on OmniPay when changing a float to a string, as the string it creates will depend on the accuracy that the current PHP system is set up.
To avoid some unexpected results on a system setting that is not under the control of a currency package, you can use sprintf() to force a specific accuracy each time, instead of leaving it for PHP to use whatever precision setting it happens to have.

Hey @judgej
Thanks for reporting the issue, good catch.
If you have already fixed this issue, can you link us to an existing solution/in what context you used this? Just for curiosity. Thanks

The proposed fix is here: https://github.com/thephpleague/omnipay-common/pull/70/files
If you both agree that's a good solution, that would be great :)

Frankly, I do not get why this an issue of Money. The conversion to float does not happen in this library, right?

You are right, Money does not accept other than an integer value. However, it is an issue of Number object, which we might use in a PreciseMoney.

There's a PR here.
I say a constructor with an open parameter that did (string)$number, so assuming a float could go into that constructor (since nothing is stopping that ATM) then that's why this is a heads up.

@judgej Number is currently used internally. From Money's public API there is no way you pass a float value in, but there is a chance that the Number class will be used in the future where this could actually cause an issue (PreciseMoney).

@judgej Ah, alright. You are consuming the Number class standalone. I get it. PR is on the way.

Fix pushed, waiting for PR to be merged.

PR merged, this can be closed I guess. Thanks everyone.

That was a whirlwind of a change. Thanks!


Thumbnails adjustment

Is there any way to resize thumbnails size?

You mean the height of the thumbnails collection view or the aspect of its cells?

I mean height of thumbnails collection, but its also good to know about aspect of cells


Inconsistent Output: Clear Results in Notebook vs. Noisy Responses in Inference Client

I’m new to AI/ML engineering, so please forgive me if I’m overlooking something obvious.
When using the notebook, the results are clear and seem aligned with the prompts. However, with the inference client, I mostly encounter noise or responses that don’t appear to understand the input. The output often lasts only 3–4 seconds before stopping.
I’m unsure if this is the intended behavior of the base model, requiring training for better performance, or if there might be an issue on my end, such as problems with microphone input affecting the model’s performance.
Any guidance would be greatly appreciated!

btw I've tried it on different GPUs (RTX 4090, A6000, H100)


[libmariadb]Disable test build.

The test project build relies on cctap.lib and the library is not found(LNK1104).
Although we can fix it, we don't need it. So I disabled the test project.
Related: #6562.

Just wondering, how come this error wasn't detected before the update was merged?

@OlafvdSpek , v3.0.5 still have problem. See #3962.

I see, but how that's related to the question?
Thanks for fixing BTW!

@OlafvdSpek I do not know. Maybe some macros or definitions have changed.

I kinda meant: is there no testing / continuous integration?

@OlafvdSpek The test project in the source code is usually used by the author test. Once the port is released, the port is tested, so we don't need to use the test project.

But obviously this port didn't build, did it?

It just can't build tests that we don't need.


feat(thumbnail notifications with signalr)

Codecov Report
Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (a878e4a) 79.79% compared to head (00e2db6) 79.46%.

Files
Patch %
Lines

.../Features/Images/AddImage/AddImageEventConsumer.cs
61.53%
5 Missing :warning:

...geHub.Api/Features/Thumbnails/Hubs/ThumbnailHub.cs
75.00%
0 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@               Coverage Diff               @@
##           development      #27      +/-   ##
===============================================
- Coverage        79.79%   79.46%   -0.33%
===============================================
  Files              110      111       +1
  Lines             1257     1276      +19
  Branches            69       70       +1
===============================================
+ Hits              1003     1014      +11
- Misses             222      228       +6
- Partials            32       34       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Proposal: Add QARTOD quality flag names to standard name list

UPDATE: This proposal has been revised; please see the latest version in the comments below.
The original proposal is below.

We are proposing adding QARTOD quality flag names to the standard name list. Adding these flags allows us to define exactly which dataset variable represents the results of a particular QARTOD test for a particular data variable. This is related to the recently added quality_flag standard name, but is more specific to QARTOD.
Note: We were originally trying to achieve this with a flag_methods variable attribute but decided to try the standard_name approach instead. More background: https://github.com/cf-convention/cf-conventions/issues/205
Proposed names:

Name
Description
Units

qartod_aggregate_quality_flag
This flag is a summary of all QARTOD quality tests run for another data variable, and is set to the highest-level (worst case) flag found. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_gap_test_quality_flag
Result of the QARTOD Timing/Gap test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_syntax_test_quality_flag
Result of the QARTOD Syntax test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_location_test_quality_flag
Result of the QARTOD Location test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_gross_range_test_quality_flag
Result of the QARTOD Gross Range test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_climatology_test_quality_flag
Result of the QARTOD Climatology test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_spike_test_quality_flag
Result of the QARTOD Spike test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_rate_of_change_test_quality_flag
Result of the QARTOD Rate of Change test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_flat_line_test_quality_flag
Result of the QARTOD Flat Line test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_multi_variate_test_quality_flag
Result of the QARTOD Multi-variate test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_attenuated_signal_test_quality_flag
Result of the QARTOD Attenuated Signal test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

qartod_neighbor_test_quality_flag
Result of the QARTOD Neighbor test. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

Example usage:
variables:

    float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:units = "1";
        sea_water_practical_salinity:long_name = "Salinity";
        sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg sea_water_practical_salinity_qc_flat_line_test";

    int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity QARTOD Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = "status_flag qartod_aggregate_quality_flag";
        sea_water_practical_salinity_qc_agg:missing_value = 2;
        sea_water_practical_salinity_qc_agg:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_agg:flag_values = 1, 2, 3, 4, 9;

    int sea_water_practical_salinity_qc_flat_line_test(time, z);
        sea_water_practical_salinity_qc_flat_line_test:long_name = "Salinity QARTOD Flat Line Test Flag";
        sea_water_practical_salinity_qc_flat_line_test:standard_name = "status_flag qartod_flat_line_test_quality_flag";
        sea_water_practical_salinity_qc_flat_line_test:missing_value = 2;
        sea_water_practical_salinity_qc_flat_line_test:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_flat_line_test:flag_values = 1, 2, 3, 4, 9;

@mwengren @kwilcox @kevin-obrien

If a variable is carrying multiple QC flags as ancillary variables then some means of identifying which flag is which is obviously needed and the Standard Name is one way of doing this. However, this could potentially create thousands of Standard Names so I wonder if using standard name modifiers might be a better way to go. That way only twelve new concepts would need to be set up to cover this requirement.

@roy-lowry Are you proposing that in addition to the status_flag on the quality variables that we add one of (12) new modifiers that describes the type of quality check without the indication that it was the qartod implementation of the test? Sort of a sub-modifier that modifies the already existing status_flag modifier? Is there some precedence or another example where this happens in CF?
example of the (12) new modifiers

aggregate
gap_test
syntax_test
location_test
gross_range_test
climatology_test
spike_test
rate_of_change_test
flat_line_test
multi_variate_test
attenuated_signal_test
neighbor_test

If I understand your suggestion, you are trying to avoid every single implementation of a quality check from having to be a specific standard name. I agree, that would be tedious, we are only proposing the QARTOD specific standard names because they are published standards. Not every quality check would be applicable and we could have the conversation on a case-by-case basis.

I really prefer the flag_methods approach - it seems much simpler to me.
In either case, providing the fact that the tests are defined by QARTOD could be accomplished with an attribute. This could be as simple as adding something like 'QARTOD_tests_V1'  to the global 'Conventions' attribute, though that would prohibit mixing different test methods.
For a more flexible approach, you could provide it as a variable attribute on the status_flag (or flag_methods, if you go that route) instead:
int PSAL_qc_agg(t, z);
PSAL_qc_agg: standard_name = "status_flag aggregate_quality_flag";
PSAL_qc_agg: vocabulary = "QARTOD_tests_V1";
Note, I think you DO need to include a version number somehow - everything changes, eventually.

Nan's suggestion works for me. My only concern is that we don't start down a road where the variable identifier and quality flag identifier are embedded into the Standard Name. Initial intentions of limited usage can easily be broken down by future use cases.

I'm not sure that you couldn't do this without any change to the CF standard, just by including a link to the relevant test, as you did in the other issue (205).
PSAL_qc_agg:standard_name = "status_flag";
PSAL_qc_agg:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
PSAL_qc__agg:flag_values = "1, 2, 3, 4, 9";
PSAL_qc__agg:references = "https://axiom-data-science.github.io/ioos_qc/aggregate_flag";
The text in flag_meanings is also completely unrestricted, so you could use something like:
   PSAL_qc_agg:flag_meanings = "qartod_aggregate_pass qartod_aggregate_not_evaluated
                   qartod_aggregate_suspect qartod_aggregate_fail qartod_aggregate_missing"

That seems to contain all the information - as long as you include the 'references' attribute, pointing to the qartod_aggregate scoring method.
This could be implemented - and documented - by IOOS, and become a sort of de facto standard.  Or, CF could certainly adopt some part of this - e.g. formalizing the 'references' attribute for status flags.

@roy-lowry, re: your earlier comment:

My only concern is that we don't start down a road where the variable identifier and quality flag identifier are embedded into the Standard Name.  Initial intentions of limited usage can easily be broken down by future use cases.

I am not sure I understand what you mean here about variable and quality flag identifiers in the standard name.  I recognize your concern about adding an unknown number of future QARTOD or other status/quality flag identifiers beyond the 12 we list here, however I'm confused because there is no 'variable identifier' in these names, only identifiers for the QARTOD tests.  These test names have been developed as part of the QARTOD project here at the US IOOS office, and have been adopted by groups outside of IOOS.
QARTOD test names may not quite match the intent of the standard names table, I recognize.  In fact, this proposal is our second attempt at a way to make our use case fit with existing CF conventions (and therefore hopefully be more stable and adopted outside of our own community).  The approach of adding QARTOD test names to the standard names table was recommended initially by @martinjuckes in discussion about our initial proposal (#205) to add the 'flag_methods' attribute, and we decided for our needs it is simpler to apply and easier to understand.  The drawback being that the standard names table must serve as a vocabulary for the breadth of QARTOD test names (or other similar such names).
We think that even though there are many (over 100 perhaps) QARTOD test names in existence, few of them are implemented currently and we feel pretty confident these initial 12 will get us quite far for present needs.  If the open-endedness of setting a precedent like this is too much of a concern though, what about our initial proposal of 'flag_methods' (#206), coupled with an externally-managed vocabulary referenced by URI in the file?
It seems that being able to characterize the process/procedure of the 'flag_values/flag_meanings' variables in some standard way is of benefit to CF from discussion in both issues.
How does the decision making process work from here?  We'd like to continue to move that forward and advocate for one of our two proposals (whichever is more agreeable to those who wish to weigh in).
Some of the alternatives proposed here, although workable, are somewhat less concise and/or not as easily machine readable as either of our two proposals (machine readability is one of our primary goals in the design).
Thanks for your continued consideration.

Dear Micah,
I think there is some degree of misunderstanding here, so I will try and clarify. What I am trying to prevent is having to create up to a dozen new Standard Names for every measurement, such as:
'sea_water_practical_salinity_gap_test'
'sea_water_practical_salinity_neighbor_test'
'sea_water_practical_salinity_at_sea_floor_gap_test'
'sea_water_practical_salinity_at_sea_floor_neighbor_test'
At its inception CF proposed a mechanism to prevent this kind of proliferation by parameter statistics (mean, standard deviation, maximum, minimum etc.) through Standard Name modifiers called Cell Methods. This was subsequently extended by the semantically broader Standard Name Modifiers. These are formally-defined terms (in Appendix C of the CF Conventions document - possibly should also be in NVS as a vocabulary, but that's another issue) that are included in the Standard Name strings separated by a space. So the above examples become:
'sea_water_practical_salinity gap_test'
'sea_water_practical_salinity neighbor_test'
'sea_water_practical_salinity_at_sea_floor gap_test'
'sea_water_practical_salinity_at_sea_floor neighbor_test'
The difference is possible hard to spot. One underscore has been replaced by a space in each case. The big difference is in the work needed for implementation. Adding the 12 QARTOD tests would require adding 12 entries to Table C1 in the Conventions document. These are then available to modify every existing - and still to be created - Standard Name.  This is the full description of my proposal above and is exactly as understood by @kwilcox in the comment above.
Nan proposed an alternative mechanism that would require one Standard Name setting up per QARTOD flag. I stated that I could live with this as it addressed my primary concern of preventing a proliferation of Standard Names. It could work - don't forget the flags are linked to their variables through ancillary variable attributes - but is possibly more opaque than the Standard Name Modifier route. As I think more about it I am less attracted to it.
I would suggest that the best way to take things forward would be for the proposers of this ticket to decide and state their preference out of the three alternatives in the above discussion namely:

As proposed (up to 12 new Standard Names per measurement)
Using Standard Name Modifers
Using flag_methods

and see where the discussion goes from there.

I am in favor of @roy-lowry's options 2 or 3.

@roy-lowry Just to clarify, we aren't proposing what you described above.  So Option 1 in your list above is incorrect.  The QARTOD test names - although specific to QARTOD - wouldn't require the test name to be attached to any existing geophysical or other measured parameter standard name.   So the examples you listed like sea_water_practical_salinity_gap_test name is not something we're advocating for here.
It sounds like you're conflating @ngalbraith's suggestion with our original proposal somewhat.  We're proposing in this issue the addition of 12 QARTOD test names in the standard names table (to begin with), which are ancillary to the actual measured variable and leverage the ancillary_variables/status_flag approach already within CF to define the association.  Minimal example:
float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg sea_water_practical_salinity_qc_flat_line_test";

int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity QARTOD Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = "status_flag qartod_aggregate_quality_flag";

int sea_water_practical_salinity_qc_flat_line_test(time, z);
        sea_water_practical_salinity_qc_flat_line_test:long_name = "Salinity QARTOD Flat Line Test Flag";
        sea_water_practical_salinity_qc_flat_line_test:standard_name = "status_flag qartod_flat_line_test_quality_flag";

Because QARTOD is a published standard approach to real-time quality control, we felt the specific test names it defines were appropriate to include in the standard names table (i.e. as an accepted standard practice by multiple oceanographic groups).  Of course, this would be setting a precedent for additional names to be added in the future (even additional programs similar to QARTOD) which I agree is a risk/concern, and may be counterproductive.  We feel the 12 will meet our foreseeable needs, however.
I think Option 2, or 'Standard Name Modifiers' as listed would work as well, however you would still need to associate the measured variable with the ancillary flag variable(s) using the :ancillary_variables I think right?  There may be multiple sea_water_practical_salinity variables in the same file, after all.
Option 3 'flag_methods' is akin to Option 1 (as we intended it), just with the flag/test name vocabulary that should be used to be maintained in an external system and not written into the CF conventions anywhere.
We haven't had a chance to discuss this within our group, but I just wanted to clear up misconceptions in the meantime.  Thanks for everyone's input on this.

Many thanks for this clarification and apologies for misunderstanding your original proposal, partly due to not realising that there was a scroll bar on the window and so only seeing a truncated version of the example. I'll get used to GitHub one day!
Now I understand what you are requesting it has my support.  @ngalbraith 's point about incorporating versioning could be addressed by including a versioned QARTOD reference in the Standard Name definitions. I don't feel that inclusion of version numbers in Standard Names is a precedent to set here.

I can't support including the word QARTOD in the list of test names. These basic tests are used in many communities, in data that's not real time and in non-ocean data areas. The test details are not always exactly the same as the QARTOD versions, and there may be additional tests that QARTOD will not want to document. The list will spiral out of control if we have to identify the test publisher within the standard name list - I thought we had covered this ground earlier.
The test authority, along with the versioning info, should be named elsewhere, in an attribute. E.g.
int psal_qc_agg(time, z);
psal_qc_agg:long_name = "Salinity QARTOD Aggregate Flag";
psal_qc_agg:standard_name = "status_flag aggregate_quality_flag";
psal_qc_agg:vocabulary = "QARTOD tests V1.1";
psal_qc_agg:reference = "https://ioos.noaa.gov/QARTOD tests/V1.1/Aggregate_score.html";

Looks like a fundamental issue here is whether or not QARTOD is a sufficiently well-developed, supported and respected standard for the label to convey semantics that add value to a Standard Name or Standard Name Modifier. My impression/understanding is that this is so but @ngalbraith obvious disagrees strongly.
So, if this proposal is going to get anywhere the community behind it has to decide if they are happy to lose the 'QARTOD' references or find additional support for their inclusion from the CF community.
A couple of additional comments of technical detail brought to mind by @ngalbraith 's last comment.

The specific tests are treated as Standard Name Modifiers of the Standard Name 'status_flag', not Standard Names. I strongly suspect that if the tests were added to Table C1 they would be appended to measurement Standard Names rather than 'status_flag' in common usage even though this is less semantically correct. Making the tests Standard Names rather than Standard Name Modifiers would prevent this.

If the QARTOD is removed from the labels then the definitions would need to be rewritten to explain what the tests are.

Whilst 'long_name' and 'standard_name' are part of the CF Conventions, I don't think that 'vocabulary' and 'reference' are.

I think the question is "to what extent should a standard name be specific to a particular implementation?" (rather than how well-developed, supported and respected QARTOD is). Because there will be many non-QARTOD implementations of these tests.  So, where should the abstraction be made? I understand the general principle of CF is to encourage interoperability by labeling the result, not any unique process for obtaining the result. (So that I can find, e.g, all the variables that have flat line test results, and at first level treat them as comparable.)
Of course it will be the case that specific algorithms (and their parameterizations) will differ, whether QARTOD vs MBARI or QARTOD v1 vs QARTOD v2. Just as the specific techniques differ by which a salinity value is obtained, these techniques will differ under the covers, and users will have to decide how deep they want to dive into detailed provenance information about the processing.

We discussed this internally and came up with the following:
(1) We agree that removing the QARTOD from the test names is fine, since the result is still perfectly useful for our cases, and in fact makes the names more generic and widely useful.
(2) It's clear from this thread that we are in a gray area between Standard Names and Standard Name Modifiers. But we prefer adding these as Standard Names rather than modifiers.
(3) Since vocabulary and references are not part of the CF conventions, that isn't explicitly part of our proposal. Even without those attributes we believe the standard name alone conveys useful information. We will enforce use of these attributes in our own metadata profile, which is built upon CF and other standards.
Since this has had a lot of back-and-forth, we've updated our original proposal and pasted it below. We removed references to QARTOD, added descriptions of each test, and updated the proposal description.
Again, thank you everyone for all the great input.

Updated proposal:
We are proposing adding quality test flag names to the Standard Name list. Adding these flags allows us to define exactly which dataset variable represents the results of a particular quality test for a particular data variable. While the list below is not comprehensive -- that is, it does not contain a full list of every possible quality test that could be run -- as it stands it we meet our needs for the foreseeable future. If accepted, we expect others will propose expanding this list to include other testing methods as needed.
Proposed names:

Name
Description
Units

aggregate_quality_flag
This flag is a summary of all quality tests run for another data variable, and is set to the highest-level (worst case) flag found. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

gap_test_quality_flag
Result of the Timing/Gap test, which checks that data has been received within the expected time window and has the correct time stamp. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

syntax_test_quality_flag
Result of the Syntax test, which checks that the data contains no indicators of flawed transmission. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

location_test_quality_flag
Result of the Location test, which checks that a location is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

gross_range_test_quality_flag
Result of the Gross Range test, which checks that values are within reasonable range bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

climatology_test_quality_flag
Result of the Climatology test, which checks that values are within reasonable range bounds for a given time and location. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

spike_test_quality_flag
Result of the Spike test, which checks that the difference between two points in a series of values is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

rate_of_change_test_quality_flag
Result of the Rate of Change test, which checks that the first order difference of a series of values is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

flat_line_test_quality_flag
Result of the Flat Line test, which checks for consecutively repeated values within a tolerance. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

multi_variate_test_quality_flag
Result of the Multi-variate test, which checks that values are reasonable when compared with related variables. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

attenuated_signal_test_quality_flag
Result of the Attenuated Signal test, which checks for near-flat-line conditions using a range or standard deviation. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

neighbor_test_quality_flag
Result of the Neighbor test, which checks that values are reasonable when compared with nearby measurements. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

Example usage:
variables:

    float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:units = "1";
        sea_water_practical_salinity:long_name = "Salinity";
        sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg sea_water_practical_salinity_qc_flat_line_test";

    int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = "aggregate_quality_flag status_flag";
        sea_water_practical_salinity_qc_agg:missing_value = 2;
        sea_water_practical_salinity_qc_agg:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_agg:flag_values = 1, 2, 3, 4, 9;

    int sea_water_practical_salinity_qc_flat_line_test(time, z);
        sea_water_practical_salinity_qc_flat_line_test:long_name = "Salinity Flat Line Test Flag";
        sea_water_practical_salinity_qc_flat_line_test:standard_name = "flat_line_test_quality_flag status_flag";
        sea_water_practical_salinity_qc_flat_line_test:missing_value = 2;
        sea_water_practical_salinity_qc_flat_line_test:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_flat_line_test:flag_values = 1, 2, 3, 4, 9;

@roy-lowry , @ngalbraith and @JimBiardCics , have you had a chance to look at our updated proposal? You've given a lot of great feedback and ideas so far, and we're curious to hear what you think of our latest updates. Thanks!

@jessicaaustin I have been hanging fire to see if new watchers coming onto GitHub brings any additional comment. It's the next job on my CF work list.

@stephenworsley @lbdreyer  How would having the labels 'aggregate_quality_flag' etc. as Standard Names rather than Standard Name Modifiers (e.g. 'status_flag aggregate_quality_flag' affect the iris software development project? What would your preference be?

I am happy with the text for labels and definitions in the revised proposals as either Standard Names or Standard Name Modifiers. However, I am becoming concerned about their being Standard Names.
In the revised proposal example the new concepts are implemented as Standard Names with the Standard Name Modifier 'status_flag'. But the status_flag entry in Appendix C of the Conventions is qualified by the text:
'The use of this modifier is deprecated and the standard_name status_flag is preferred to describe this type of metadata variable.'
So, that leaves the possibilities 'aggregate_quality_flag' or 'status_flag aggregate_quality_flag'. Looking at the project that linked with this thread yesterday it can be seen that flags require specific handling code. The obvious way to trigger this is to look for 'status_flag' in the Standard Name. So I think 'status_flag aggregate_quality_flag' is the better way to go.

@stephenworsley @lbdreyer How would having the labels 'aggregate_quality_flag' etc. as Standard Names rather than Standard Name Modifiers (e.g. 'status_flag aggregate_quality_flag' affect the iris software development project? What would your preference be?

The difference between adding the flags as standard name modifiers versus standard name modifiers, as an impact on Iris, would be minor.
There is a slight preference for standard names. Standard names are provided in a machine readable format so any updates are pulled through easily, whereas for standard name modifiers we maintain a copy of the C1 table, so any updates to that table require us to update Iris.

So, that leaves the possibilities 'aggregate_quality_flag' or 'status_flag aggregate_quality_flag'. Looking at the project that linked with this thread yesterday it can be seen that flags require specific handling code. The obvious way to trigger this is to look for 'status_flag' in the Standard Name. So I think 'status_flag aggregate_quality_flag' is the better way to go.

I suspect we will write Iris such that it will detect whether or not something is a flag is by checking for the flag_values, flag_masks and flag_meanings attributes rather than using a standard_name. This will allow for users that may, for example, use a long_name rather than a standard_name.
So aggregate_quality_flag as a standard_name sounds perfectly sensible from an Iris perspective.

Many thanks to @lbdreyer for removing my concerns. It would certainly be easier to go down the Standard Names route as it is adding to a controlled vocabulary rather than updating the Conventions Document. Semantic information in Standard Names is also more accessible as they are in vocabulary servers whereas the Conventions text is not.
So, providing the deprecated 'status_flag' Modifier is removed then I'm happy with these flag types being Standard Names.

@roy-lowry I was going to comment about the need to remove the deprecated status_flag  standard name modifier from the conventions document, but I see you agree that's necessary too.  That will help eliminate some confusion for newcomers to CF's ancillary variable/flag syntax and how to properly apply it, I think.  It confused me to have it mentioned in two places, anyway.
While coming up with this proposal, we were cognizant of the discussion about the newly-added quality_flag standard name over the summer/fall.  I see now, given that the status_flag standard name modifier is to be truly deprecated, our files will need to only use the specific standard names we've described above (which in a way inherit from the root quality_flag name), without use of any modifiers such as status_flag.  Adapted example from earlier comment:
float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg";

int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity QARTOD Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = "qartod_aggregate_quality_flag";

I think it would be nice if the connection between our names and the quality_flag generic name could reflected better within the CF standard name table, since there's no explicit connection between them in the descriptions.   We could change our name to follow a pattern like:

quality_flag_aggregate
quality_flag_gap_test
quality_flag_syntax_test
etc...

and it would make the connection a little clearer.  At least they would start with the same letter and appear next to each other alphabetically, and might lead people to associate them more easliy.
Alternatively, we could mention quality_flag within the text descriptions of our new names.
Or, a new addition to 3.5 of the conventions document that explains the various names and includes a few examples?
Any thoughts out there about this?
I see we're starting down a path that @graybeal mentioned in the quality_flag discussion with greater specificity in our names beyond the more generic quality_flag name.  Just wondering whether it makes sense to set a precedent here, and if so, what.  Maybe too much of a rabbit hole...

@mwengren I was referring to removing the Modifier 'status_flag' from the examples in the modified proposal, not from the Conventions Document. To do that would be very much against my understanding of best practice.  Deprecation, not deletion is the way to go to deliver transparency.
Your modified example includes 'QARTOD' is the flag Standard Name, which I thought had been dropped.
I don't think it's a good idea to weave vocabulary updates into the Conventions Document text.
I prefer the Standard Name labels as presented in the modified proposal. Using alphanumeric sorting of labels to establish semantic relationships is a technique I used in the 1990s until I saw the error of my ways. What happens if somebody in the future adds another batch of Standard Names beginning 'quality_flag' that go off at a tangent to yours? There could be a way to establish a linkage between your Standard Names and the Standard Name 'quality_flag' using mappings in the vocabulary servers. I can point you in the right direction once the names are in the system.
I guess you could replace 'Result' at the start of the descriptions with 'A quality flag the reports the result'

@roy-lowry Ah, poor quality control on the quality control examples!  I fixed the error in my example above.

Using alphanumeric sorting of labels to establish semantic relationships is a technique I used in the 1990s until I saw the error of my ways.

Ok, I see your point about relying on similar alphanumeric name structure.  If there's a way to establish a linkage using mappings, that sounds much better.  I'm not too familiar with the standard name table so forgive my naive suggestions.

I guess you could replace 'Result' at the start of the descriptions with 'A quality flag that reports the result'

I am OK with making this change when these names are added - @jessicaaustin any thoughts?   Should we update the comment above with new phrasing?
I do think improved examples in Chapter 3.5 in the conventions document would go a long way to clarifying usage of the collection of 'flag' standard names.  After the lengthy discussion on the new quality_flag name, it would be shame for a newcomer to CF that wants to encode measurement quality information in CF to opt for status_flag when quality_flag (or any of the flags proposed here) might be more optimal, just  because status_flag is used in the only example (Example 3.3) shown there with a standard name.
To me, the standard names list is rather opaque, good examples go a long way to explain the intended usage.  Someone would have to read Chapter 3.5, go to the standard names page, search for 'flag', and then compare the definitions to see what name is most appropriate for their situation.  There was a lot of good background shared in that discussion on best practice, but it's basically lost unless the documentation gets an update (IMO).
Thanks for your feedback thus far.  Looking forward to merging these new terms if there's no dissent.

I support Roy's other points, but whatever experiences showed Roy the error of his ways regarding name sorting never crossed my path. ;-)  I find the wordings beginning with quality_flag considerably more intuitive, because the most important thing is that this is a quality flag, and the second most important thing is what kind of flag it is. (The aggregate_quality_flag is the only exception, I could go either way on that.)
The fact that it collects all the quality flags together in the list is a huge usability improvement, because it reflects how people often find things (by serendipitous browsing, rather than intentional searching), and creates an immediate understanding of the quality flag 'offerings' in CF. From a marketing standpoint this would have a positive impact.
{quote}What happens if somebody in the future adds another batch of Standard Names beginning 'quality_flag' that go off at a tangent to yours? {quote}
Then (presuming they are all quality flags or related) all of the quality_flag-related names are collocated, which is a good thing.
But of course I agree the relationship should be established in the definition, so all bets are covered.
Yay for improving the related examples in the Conventions document.
Alas, all of the advantages may be made moot by the semi-official constructs of the CF grammar, so I won't be surprised if there's a reason It Can't Be. Just sayin', it would be a lot more user friendly, at least for this user.

@graybeal My preference is founded by English grammar in which a qualifying adjective precedes the noun reinforced by unfortunate experiences in the past whilst building systems based on label sorting. Only we metadata geeks think in terms of semantic hierarchies! However, my feelings aren't strong enough to become a blocking issue so I'd accept whatever the proposers decide.

Catching up here. Sounds like one change we've decided to make is to remove status_flag from the recommended usage, so that
 sea_water_practical_salinity_qc_flat_line_test:standard_name = "flat_line_test_quality_flag status_flag";

becomes
 sea_water_practical_salinity_qc_flat_line_test:standard_name = "flat_line_test_quality_flag";

On the other points:

"replace 'Result' at the start of the descriptions with 'A quality flag that reports the result'" -- The latter wording would be better for searches (in case someone searches for "quality" in the description) so I like that.
quality_flag_flat_line_test versus flat_line_test_quality_flag

I predict most people are going to find these standard names through shared code, examples, open-source libraries, and searching the standard name list, so whether or not they are in ABC order can be a consideration but should not drive the decision.
I also love the idea of updating the CF document with example usage if/when this proposal is accepted, and I think that will go a long way to improve discovery and understanding. We've got a great start here with some example usage.
According to the CF standard name submission guidelines, "The order [of facets] is not rule-based; the goal is to make the name as clear and natural as possible", so we have some leeway to decide what we think is best.
So my personal preference is to keep it as flat_line_test_quality_flag
After speaking with the other proposers, we agreed to keep the original names, and make sure to focus on having clear examples, both in CF docs and our own documentation.

I've updated the original proposal again to reflect these changes: I removed status_flag from the examples, added "A quality flag that reports" wording, and kept the originally proposed names. See below.
Based on what I'm reading in this thread, it sounds like we're reaching a consensus? What are the next steps at this point, and the timing for those? Thank you!

Updated proposal:
We are proposing adding quality test flag names to the Standard Name list. Adding these flags allows us to define exactly which dataset variable represents the results of a particular quality test for a particular data variable. While the list below is not comprehensive -- that is, it does not contain a full list of every possible quality test that could be run -- as it stands it we meet our needs for the foreseeable future. If accepted, we expect others will propose expanding this list to include other testing methods as needed.
Proposed names:

Name
Description
Units

aggregate_quality_flag
This flag is a summary of all quality tests run for another data variable, and is set to the highest-level (worst case) flag found. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

gap_test_quality_flag
A quality flag that reports the result of the Timing/Gap test, which checks that data has been received within the expected time window and has the correct time stamp. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

syntax_test_quality_flag
A quality flag that reports the result of the Syntax test, which checks that the data contains no indicators of flawed transmission. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

location_test_quality_flag
A quality flag that reports the result of the Location test, which checks that a location is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

gross_range_test_quality_flag
A quality flag that reports the result of the Gross Range test, which checks that values are within reasonable range bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

climatology_test_quality_flag
A quality flag that reports the result of the Climatology test, which checks that values are within reasonable range bounds for a given time and location. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

spike_test_quality_flag
A quality flag that reports the result of the Spike test, which checks that the difference between two points in a series of values is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

rate_of_change_test_quality_flag
A quality flag that reports the result of the Rate of Change test, which checks that the first order difference of a series of values is within reasonable bounds. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

flat_line_test_quality_flag
A quality flag that reports the result of the Flat Line test, which checks for consecutively repeated values within a tolerance. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

multi_variate_test_quality_flag
A quality flag that reports the result of the Multi-variate test, which checks that values are reasonable when compared with related variables. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

attenuated_signal_test_quality_flag
A quality flag that reports the result of the Attenuated Signal test, which checks for near-flat-line conditions using a range or standard deviation. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

neighbor_test_quality_flag
A quality flag that reports the result of the Neighbor test, which checks that values are reasonable when compared with nearby measurements. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.
1

Example usage:
variables:

    float sea_water_practical_salinity(time, z);
        sea_water_practical_salinity:units = "1";
        sea_water_practical_salinity:long_name = "Salinity";
        sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
        sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg sea_water_practical_salinity_qc_flat_line_test";

    int sea_water_practical_salinity_qc_agg(time, z);
        sea_water_practical_salinity_qc_agg:long_name = "Salinity Aggregate Flag";
        sea_water_practical_salinity_qc_agg:standard_name = "aggregate_quality_flag";
        sea_water_practical_salinity_qc_agg:missing_value = 2;
        sea_water_practical_salinity_qc_agg:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_agg:flag_values = 1, 2, 3, 4, 9;

    int sea_water_practical_salinity_qc_flat_line_test(time, z);
        sea_water_practical_salinity_qc_flat_line_test:long_name = "Salinity Flat Line Test Flag";
        sea_water_practical_salinity_qc_flat_line_test:standard_name = "flat_line_test_quality_flag";
        sea_water_practical_salinity_qc_flat_line_test:missing_value = 2;
        sea_water_practical_salinity_qc_flat_line_test:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
        sea_water_practical_salinity_qc_flat_line_test:flag_values = 1, 2, 3, 4, 9;

I think this is fine. It seems clear, and limits the number of new standard names that will be needed.
Of course, if people use these without specifying the vocabulary and/or some reference to a description of the tests, they lose a lot of their meaning. My aggregate_quality_flag might represent something totally different from the QARTOD aggregate, but I think that's the trade off for limiting the number of new terms needed.
I'm not sure if we need to spell that out in the documentation somewhere, recommending some terms to help define the tests that were appliedm or if we can leave it to communities that are planning to make these standard names part of their specifications to do that.
Thanks for your patience getting this done.

@jessicaaustin and everyone else involved in this proposal and discussions, thank you very much for your time on this. It will be a great advance. I'm excited to see this concluded and start using it.
I think it could be useful to include gradient_quality_flag and density_inversion_quality_flag in this proposal. A little further, I think that it would be great to include all the tests of all standards that QARTOD was based on (Argo, GTSPP, ...). I see great power in being able to distinguish which procedure was done, but for that, the different procedures must be in the system. Someone will need to add those eventually, so why not doing it from the start?
I also have a question on something that @ngalbraith raised before. Following the latest version of the proposal, how would be the best way to identify the details of some applied test? For instance, how could I find (machine-readable) what was the upper and lower limits used for a QARTOD climatology test? Or if it was a GTSPP climatology instead, how many standard deviations was the tolerance? Which climatology was used (WOA13, WOA18, ...)? Could I have two different climatologies in the same dataset? How would be the best way to distinguish them? Thanks!

I personally think including this level of detail (number of standard deviations, upper/lower limits, gap length, name of climatology used, distance to 'neighbor' data, etc) is beyond the scope of CF; there are just too many details. Every test has its own inputs, and these may vary with different organizations using this new set of standard names. Even QARTOD tests may be implemented in different ways by different organizations, who may have different requirements for documentation.
If you feel that your data providers' quality assessments need to come with machine readable details, you could define those terms as extra required attributes for QARTOD (or more correctly, for the IOOS implementation of  QARTOD) compliance; this can be documented in the resource (web page or service, presumably) that describes the specific test. The data files would be perfectly usable without these details, but I can see why you'd want a standard vocabulary to describe the inputs. (That said, many users will simply trust the data providers' assessment anyway - and assume they chose appropriate levels for the test inputs.)
In the OceanSITES project, we assign additional required attributes to items that are part of CF (or part of another standard, like NCADD). A file can be CF compliant and not include these details, but it's not OS compliant unless it has them. The OS definitions are in our data format reference manual (and, more briefly, our other data manuals), but the web page that defines the IOOS's implementation of the QARTOD tests could include some description of the additional attributes required. e.g. for the flat_line_test:
qc_flat_line_test IOOS required attributes

standard_name = "flat_line_test_quality_flag";
flag_meanings, flag_values
min_length_points (or min_length_minutes)

@ngalbraith for the upcoming version of our 'IOOS Metadata Profile' that incorporates these new standard names into a quality flagging scheme for QARTOD, we decided to leverage the references attribute to suggest data providers link to external web pages or web-accessible files (e.g. JSON) that contain the parameters used in the tests.  The documentation for this scheme can be found here.
Our QC library is written so that JSON or YAML files can be passed to the test functions to define the parameters, so there is a way for a direct integration there.  @jessicaaustin can correct me if I have any of this wrong.
@castelao I don't have an opposition to adding additional test names to this proposal, however we do have a strong preference that these names be added to the next release of the standard names table (v71) so we can move our project along to the implementation phase - we've been waiting on resolution here.
If the CF stewards are willing to accept additional tests and merge them alongside those we've proposed, then I don't see a problem.  It may make sense to open a new issue with the full list of additional test names, descriptions, etc, as in the tables above and refer back to this one (via cf-convention/cf-conventions#216 link) rather than include them in the same issue.  Just my 2 cents.  Thanks!

The external files are fine, but there's one problem with using the 'references' attribute; that term is defined as a global attribute in CF. Most netCDF software does not handle a situation where a term is used as a global and a variable attribute the way you might expect -  that's apparently a feature (and has caused problems with oceansites data).
I haven't had a chance to check your Metadata Profile yet; I hope you're also using the Conventions attribute, with a version number, for your IOOS details.

Thank you Nan and Alison for your comments and suggestions.
I think we're all still in agreement on the standard name list, including Alison's suggestions for additional text to add to the non-aggregate flag names. The wording and scope for the aggregate flag still needs more clarification though.
After some internal discussion, here's our proposed revision for the aggregate_quality_flag definition:
Original: This flag is a summary of all quality tests run for another data variable, and is set to the highest-level (worst case) flag found. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute
Proposed (differences highlighted): This flag is a summary of all relevant quality tests run for the related ancillary parent data variable, and is set to the highest-level (worst case) flag found. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute.  The aggregate quality flag represents the summary of all quality tests performed on the data variable, whether automated or manual, and whether present in the dataset as independent ancillary variables to the parent data variable or not.
Our justification:
Through this process, we have specifically decided to not use the word QARTOD in our standard names, which means we are leaving these flags open to describe any kind of QC process: QARTOD, some other well-known testing scheme, human-in-the-loop testing, etc -- or even some combination of all these. These processes are complex and therefore difficult to describe completely using variable attributes.
We are trying to strike a balance between keeping things simple and generic, while still being descriptive enough to be useful. Introducing a way to describe a single roll-up/aggregate/summary QC flag for a variable is extremely powerful! It is especially useful when it comes to writing scripts that use this data, which is the main motivation for this proposal. So we want to keep aggregate_quality_flag broad enough to encompass all kinds of testing that might happen on a data variable. We also want to make it easy enough to understand and use, so that it is widely adopted.
In that same vein, we are purposefully leaving out any specifics on how to define exactly what tests contributed to the aggregate flag. An external script would treat aggregate_quality_flag the same no matter how it was constructed. A human might want to know what tests made up the aggregate flag, but they could look to links or text elsewhere in the dataset metadata that describes the QC process (long_name, comments, references, history, etc). Again, this is to strike a balance between being descriptive and being easy to use.
An example:
Consider a scenario where you have QARTOD running in real-time as your data comes in, and you also periodically do human-in-the-loop testing. The QARTOD tests are very well-defined, but the HIL testing is not -- maybe you have a combination of MATLAB scripts and manual flagging based on plots, for example. So in terms of the dataset, you could have something like:
float sea_water_practical_salinity(time, z);
    sea_water_practical_salinity:units = "1";
    sea_water_practical_salinity:long_name = "Salinity";
    sea_water_practical_salinity:standard_name = "sea_water_practical_salinity";
    sea_water_practical_salinity:ancillary_variables = "sea_water_practical_salinity_qc_agg sea_water_practical_salinity_qc_gross_range_test sea_water_practical_salinity_qc_manual";

int sea_water_practical_salinity_qc_agg(time, z);
    sea_water_practical_salinity_qc_agg:long_name = "Salinity Summary QC Flag";
    sea_water_practical_salinity_qc_agg:standard_name = "aggregate_quality_flag";
    sea_water_practical_salinity_qc_agg:missing_value = 2;
    sea_water_practical_salinity_qc_agg:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
    sea_water_practical_salinity_qc_agg:flag_values = 1, 2, 3, 4, 9;

int sea_water_practical_salinity_qc_gross_range_test(time, z);
    sea_water_practical_salinity_qc_gross_range_test:long_name = "Salinity Gross Range QC Test Flag";
    sea_water_practical_salinity_qc_gross_range_test:standard_name = "gross_range_test_quality_flag";
    sea_water_practical_salinity_qc_gross_range_test:missing_value = 2;
    sea_water_practical_salinity_qc_gross_range_test:flag_meanings = "PASS NOT_EVALUATED SUSPECT FAIL MISSING";
    sea_water_practical_salinity_qc_gross_range_test:flag_values = 1, 2, 3, 4, 9;

int sea_water_practical_salinity_qc_manual(time, z);
    sea_water_practical_salinity_qc_manual:long_name = "Salinity Manual Review QC Tests Flag";
    sea_water_practical_salinity_qc_manual:standard_name = "quality_flag";
    sea_water_practical_salinity_qc_manual:missing_value = 2;
    sea_water_practical_salinity_qc_manual:flag_meanings = "PASS FAIL_BIOFOUL FAIL_INSTR FAIL_TELEM";
    sea_water_practical_salinity_qc_manual:flag_values = 0, 1, 2, 3;

(And hopefully you describe or link to your overall qc process, including HIL testing, somewhere in the global metadata!)
The manual tests and results could be very specific to your group -- in this example for the manual tests the data point could either be PASS, or could FAIL due to instrument issues, bio-fouling, etc.
While the QARTOD flat line test and the manual HIL tests involve different processes and flagging schemes, at the end of the day they should be somehow combined in a single QC result per data point. How you do that combination can be as arbitrary and complex as the QC process itself. This is where the aggregate_quality_flag is useful: the proposed definition gives you plenty of flexibility to include or exclude specific test results in your aggregate flag, depending on whether or not it is relevant at any given time.
Furthermore, we have come across scenarios where a group has a single qc flag per variable, that they update during periodic data reviews. In that case, the QARTOD and HIL variables would not be present -- just the "aggregate" flag. Hence the wording at the end: "whether present in the dataset as independent ancillary variables to the parent data variable or not".
Answers to specific questions from Alison and Nan
From Alison:

If we were to add standard names for more QARTOD defined quality tests, as has already been suggested, would the results of those tests then also form part of the aggregate?

Yes, if they were relevant. It's up to the operator to decide which variables are used for the aggregate flag
A script would treat the aggregate_quality_flag variable the same in either case. A human could look for documentation if they needed to know specifically what tests were used to create the aggregate flag

Would the aggregate flag include the results of quality tests that were defined by some standard other than QARTOD if they happened to appear in the same data file?

Same answer as above

From Nan:

There are cases when a test is run and the results are not considered important for some reason - failing a spike test because of data is determined to represent an actual measurement, or ... failing a gap test because of poor telemetry. The point of the long drawn out discussion was in part to make sure these standard names could be used by other QC systems; letting those systems document their own method of setting the value of the aggregate is important.

Yes, we agree with this sentiment
Nan, do you agree that the proposed new wording is flexible enough to allow for this scenario?

I'd like to have some text describing the best way to convey the name of the QC system being used - maybe a recommended attribute on each of these quality variables? That would solve the problem of people mixing QARTOD and other tests. Can we do that in the standard name guidance, or does QARTOD need to describe that themselves?

If a test has a name flat_line_test_quality_flag, does it really matter what QC system was used to create it? Isn't that the whole point of creating a generic standard_name for the test?
If the QC system used is relevant to a user, we think that providing an overall description of the QC process (or a link to it) elsewhere in the dataset metadata is a simple yet effective way to convey this information

Also, could we recommend that the aggregate have a way to list its component tests? These could be given as ancillary variables.

We believe this adds too much complexity without enough benefit. If the information is relevant to a user, then it could be listed in a global or variable attribute. But since this information is for humans and not scripts, we don't think it makes sense to create a strict definition here.

There seems to be a contradiction creeping in between the aggregate_quality_flag definition and Jessica's answers to Alison's questions. The answers indicate a move towards a generic position in which the component parts of the aggregate are a moveable feast.
However, the definition includes a prescription of the algorithm to be used for the synthesis of the component flag values. Would it not be possible for another user of the Standard Name to have an algorithm that applied weightings to the different components. That is why Nan was objecting to  the phrase 'set to the highest-level (worst case) flag found'.
So I think you need to take one final step down the road to a generic aggregate_quality_flag. Maybe something like:
This flag is an algorithmic combination of the results of all relevant quality tests run for the related ancillary parent data variable. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute. The aggregate quality flag provides a summary of all quality tests performed on the data variable (both automated and manual) whether present in the dataset as independent ancillary variables to the parent data variable or not.

This is all an improvement. I like Roy's change to the definition of the aggregate flag, 'an algorithmic combination of the results of all relevant quality tests', in place of 'set to the highest-level (worst case) flag found'.
I DO have an issue with the term 'related ancillary parent data variable,' which I think could be shortened to the 'subject data variable', 'parent data variable', or something similar.
And, I'm not sure I agree with the decision to intentionally NOT describe what went into the aggregate - doesn't this render it more or less useless? A handful of new tests might be run on, and added to, a file, without updating the existing aggregate_quality_flag. This would lead to the assumption that the agg flag represented a lot of testing, when in fact it did not.
I'd still like to use the ancillary_variable attribute to explicitly tie the component tests to the aggregate, but that doesn't cover the case of files where the components are not included in the data file. Could we recommend an attribute like 'component_tests' for this?
The case where tests are run that follow different standards also seems to require an additional attribute. If the aggregate isn't going to define the testing system used, then maybe all the _quality_flag variables need to indicate which standard was used.
So here is what I'd like to see:
This flag is an algorithmic combination of the results of all relevant quality tests run for the related data variable. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute on the data variable. The aggregate quality flag provides a summary of all quality tests performed on the data variable whether present in the dataset as independent ancillary variables or not. It is highly recommended that the aggregate_quality_flag have an attribute 'component_tests' that includes the test standards and test names, e.g.
int psal_qc_agg(time, z);
psal_qc_agg:standard_name = "aggregate_quality_flag";
psal_qc_agg:component_tests = "QARTODv1.1_SpikeTest, QARTODv1.1_RateOfChangeTest, QARTODv1.1_FlatLineTest";
Is that too much information for the data user to expect? Of course, we can always implement this additional info outside of CF, if it seems too detailed for the standard name guidance.

I disagree that not describing the aggregate components through the Standard Name makes it useless. I can think of use cases where such minimal semantics are all that is needed (e.g. somebody who just wants to know which of a raft of flags to use to filter out problem data).
There are of course other use cases where the user wants to know how the aggregate was derived but in these cases I feel the user wants to know the whole story. As this issue has developed the complexity of the story has increased to the extent where I believe it has exceeded the limited semantic capabilities of CF. Consequently, I believe this story belongs in the data documentation as Jessica has suggested a couple of times.

"e.g. somebody who just wants to know which of a raft of flags to use to filter out problem data" -- Yes, this is our primary use case.
I think we all agree that in some cases the user wants to know exactly how the aggregate QC flag was derived. But we may not reach an agreement today on whether or not the data documentation is sufficient, or something like component_tests is necessary. That said, I don't think accepting this proposal as-is -- just adding a set of standard names to the table -- would preclude adding something like that in the future. Could we split that discussion into a separate issue so that we can close this one out?
Also, we are fine with Roy's most recent wording:
This flag is an algorithmic combination of the results of all relevant quality tests run for the related ancillary parent data variable. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute. The aggregate quality flag provides a summary of all quality tests performed on the data variable (both automated and manual) whether present in the dataset as independent ancillary variables to the parent data variable or not.

This is fine with me. I think there are more words than needed in the text - e.g.  'both automated and manual' is superfluous, IMHO, and 'related ancillary parent data variable' is somewhat redundant, but I agree that overall this is ready to go. Thanks for your patience!

@ngalbraith I think we added the 'both automated and manual' clause to account for the case in Jessica's example in the above comment, where there's a test with the generic quality_flag name that is manually performed with its own flagging scheme that is combined with the gross_range_test_quality_flag automated test which follows a different flagging scheme.
I think it also generally conveys the point that an aggregate flag is the one that a data user should query if they want to obtain the best data as @roy-lowry mentioned, however it was determined to be so - which also goes to your point above about how 'letting those systems document their own method of setting the value of the aggregate is important'.  We were trying to add some flexibility in the definition.
I think we've come to agreement, however, so I don't want to sidetrack, hoping this helps explain that particular phrasing and why we chose to include it.
@japamment can we close the book on this addition when you are able to revisit it again, I suppose after the three week holding period?  Many thanks for everyone's input on this.

@jessicaaustin @mwengren @ngalbraith @roy-lowry many thanks for all your comments and responses to my questions. This discussion has helped me to understand much better the ways in which quality information is gathered and used.
Regarding the 'non aggregate' names, I think we are all agreed and no further comments have been received. Hence, these names are accepted for publication in the standard name table and will be included in the next update, scheduled for 9th March. (N.B. The three week period that Micah mentioned applies to the process for modifying the main CF conventions document. For standard names it is our usual practice to accept names once all discussion points have been answered and consensus has been reached among those contributing to the conversation).
For the aggregate name it seems consensus has been achieved on:
aggregate_quality flag
'This flag is an algorithmic combination of the results of all relevant quality tests run for the related ancillary parent data variable. The linkage between the data variable and this variable is achieved using the ancillary_variables attribute. The aggregate quality flag provides a summary of all quality tests performed on the data variable (both automated and manual) whether present in the dataset as independent ancillary variables to the parent data variable or not.'
This name is also accepted for publication in the standard name table and will be added in the March update.
All the names, units and definitions are listed in full in the CEDA standard names editor.
I agree that it is important to know where to 'draw the line' between CF metadata and other sources of documentation. I do think it would be useful to use a CF attribute to state which quality control procedure has been used and hence guide data users to the appropriate documentation. This could perhaps be achieved using an existing attribute such as 'comment', which has the advantage of not needing to modify the CF conventions. It could also be achieved by adding a new attribute such as component_tests suggested by Nan. That discussion can certainly be the subject of a separate issue.
Whatever is decided ultimately, we could then update the standard name definitions by adding a sentence advising which other attribute(s) to check. For example, we currently have a lot of emissions names such as tendency_of_atmosphere_mass_content_of_alcohols_due_to_emission_from_solvent_production_and_use whose definitions say '"Solvent production and use" is the term used in standard names to describe a collection of emission sources. A variable which has this value for the standard_name attribute should be accompanied by a comment attribute which lists the source categories and provides a reference to the categorization scheme, for example, "IPCC (Intergovernmental Panel on Climate Change) source categories 2F and 3 as defined in the 2006 IPCC guidelines for national greenhouse gas inventories". Perhaps a similar approach would work for quality tests?
Best wishes,
Alison

These changes have been published in version 72 of the standard name table.
Please close this issue if all discussions are complete.

@feggleton thanks for publishing the names. I'm closing this issue now.

@feggleton @japamment @ngalbraith @roy-lowry and others: thanks for publishing the names, contributing to the discussion, and helping steer this through to acceptance!


Deprecate utils.is_str

We don't support Python 2 since a long time now

Codecov Report

Merging #168 (2fea9c1) into develop (ce011e1) will decrease coverage by 0.04%.
Report is 2 commits behind head on develop.
The diff coverage is 84.61%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           develop     #168      +/-   ##
===========================================
- Coverage    91.71%   91.68%   -0.04%
===========================================
  Files          138      138
  Lines        10736    10734       -2
===========================================
- Hits          9847     9841       -6
- Misses         889      893       +4

Flag
Coverage Δ

unittests
91.68% <84.61%> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

src/pygccxml/parser/linker.py
90.09% <0.00%> (-0.05%)
:arrow_down:

src/pygccxml/utils/utils.py
73.45% <0.00%> (-1.70%)
:arrow_down:

src/pygccxml/declarations/container_traits.py
90.27% <100.00%> (ø)

src/pygccxml/declarations/type_traits.py
91.53% <100.00%> (ø)

src/pygccxml/parser/config.py
90.22% <100.00%> (-0.05%)
:arrow_down:

src/pygccxml/parser/project_reader.py
80.00% <100.00%> (ø)

src/pygccxml/parser/scanner.py
96.28% <100.00%> (ø)

unittests/find_container_traits_tester.py
95.55% <100.00%> (-0.05%)
:arrow_down:

... and 1 file with indirect coverage changes


Base map is blank on android device

It is working fine when debugging with Chrome browser. But the base map becomes blank if I run the app on android device.

It's running just fine on Android 4.4.2 and 4.4.3 on two different devices for me locally.
Have you tried to debug it?  If you use GapDebug, you'll be able to inspect the app quite easily.

I debugged it and found those base map http requests got 404 response.
I solved the issue by:

Add the whitelist plugin: cordova plugin add https://github.com/apache/cordova-plugin-whitelist.git
And update the config.xml with:

It looks sth blocked network requests.
I am on Android 5.0 btw.

Thank you very much for problem solving!


Testnet NFTs unavailable

It looks like no NFTs can be viewed through Ripple's testnet clio node.
E.g, I'm looking at this account (https://testnet.xrpl.org/accounts/rMk8Y88QsU4dmZTs5nYe8T4NfDsRz3CRfv/assets/nft)
which has a bunch of NFTs. You can see that the testnet.xrpl.org client fails to find them. Also the following fails in the same way:
echo '{"command":"nft_info","api_version":2,"nft_id":"000801F4E3AA6C75533DE712AB7C867450638E942395C21A0000099B00000000","id":{"_WsClient":1}}' | websocat -v wss://clio.altnet.rippletest.net:51233/

{"error":"objectNotFound","error_code":92,"error_message":"NFT not found","status":"error","type":"response","id":{"_WsClient":1},"request":{"command":"nft_info","api_version":2,"nft_id":"000801F4E3AA6C75533DE712AB7C867450638E942395C21A0000099B00000000","id":{"_WsClient":1}},"warnings":[{"id":2001,"message":"This is a clio server. clio only serves validated data. If you want to talk to rippled, include 'ledger_index':'current' in your request"}]}

Note, making a nft_history call instead seems to give a success response, but the transaction array is empty.
This issue appears to be a problem across all minted NFTs AFAICT

Thanks for reporting this. We are looking into it 👍

@desimmons we tracked down the problem to the settings of the database of the public altnet Clio.
The solution is to recreate the database with the correct settings and reimport the data.
I will keep this issue open until the problem is resolved. Luckily this is not a bug in Clio's code 🙌
Once again Thank You very much for reporting this ❤

@godexsoft thanks for such a quick turn around time! Will all previously minted NFTs be visible, or will only newly minted ones be visible?

@desimmons I actually don't know yet how this will be handled by the responsible infra team. I can update this issue once I find out.

@desimmons from what I heard, the database setting is now corrected and any new transactions and minted NFTs should not be missing. However, your original NFTs are gone for the time being from Clio's history on altnet (as well as potentially anything older than 24h from right now).
The infra team is going to recreate the database from scratch in order to restore all data that got lost due to the misconfiguration and once that process is finished we should have all data back, including your previously minted NFTs. This may take anywhere between few days to a couple of weeks. Since this is a test network I hope this is not a big issue for you and you can simply mint new NFTs which now should be persisted correctly. Let me know if there is anything else we can help with 👍


New API

Implementation of new API plus first migrated function "search_cert" incl. tests.
Test classes below qatest/ are renamed from OpenXPKI::Test::* to OpenXPKI::Test::QA::*.
Some POD errors are fixed.

Coverage decreased (-5.0%) to 49.031% when pulling 2b7d3a1651dfddaac23b1e093981ad30e6a9ce43 on maxhq:new-api into 8811ceaf0c44ff0d9ad362e512fbde8542944cd8 on openxpki:develop.

Coverage decreased (-1.4%) to 52.569% when pulling 4922672a1ff94503fd71242ebcaf1c0dd768f09e on maxhq:new-api into 8811ceaf0c44ff0d9ad362e512fbde8542944cd8 on openxpki:develop.

Coverage increased (+2.08%) to 56.081% when pulling fac4d69667731aa8d2a4632c8cd8320e7fd7ffed on maxhq:new-api into 8811ceaf0c44ff0d9ad362e512fbde8542944cd8 on openxpki:develop.

Coverage decreased (-5.0%) to 49.031% when pulling dc56f27d038642626feca86c5906fa4e278a0916 on maxhq:new-api into 8811ceaf0c44ff0d9ad362e512fbde8542944cd8 on openxpki:develop.

Coverage increased (+5.5%) to 56.067% when pulling f43828243d294cb5a48e5d8982b57b36a67a9396 on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.4%) to 53.028% when pulling bf5225e554877d9e9bff02fec4a4e0dd8d51a582 on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.6%) to 53.158% when pulling 02de840b2f66a5936302d43d07dd40debf79ff58 on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.6%) to 53.158% when pulling 02de840b2f66a5936302d43d07dd40debf79ff58 on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+5.6%) to 56.251% when pulling 1a8b8665f57956b12fb8755fb3cf72348053159c on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+5.6%) to 56.251% when pulling ddbf19fb440cf18f63e8d621415c90efdeaf4b6e on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.6%) to 53.226% when pulling d10ed9870f278181b5ca9530ba9dcf7098d35fbd on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.6%) to 53.226% when pulling 69b08e3f8affc3394b8e040d04d6cc36374df6f0 on maxhq:new-api into d8e6186e9b7e231524d4895ffa43d34e2f734cb5 on openxpki:develop.

Coverage increased (+2.4%) to 56.293% when pulling d0716436a9a374f929622166b172bc1fbc7dcfd8 on maxhq:new-api into 08954e67ff4f415f990dd91bf18ef4681c3d865c on openxpki:develop.

Coverage increased (+2.4%) to 56.298% when pulling 862ae603232687302e41244460e63488084be961 on maxhq:new-api into 08954e67ff4f415f990dd91bf18ef4681c3d865c on openxpki:develop.

Coverage increased (+2.7%) to 56.632% when pulling dcb5316adcd2b345af403f0a10b3dee470927e2d on maxhq:new-api into 3c7af2dafd73ab217ddf616cdd283f24ff74bb27 on openxpki:develop.


Missing LICENSE file in npm package

Describe the bug
There is no license file included with the npm package, possibly making it illegal (not a lawyer) for it to be distributed that way. It also makes it harder for license checking tools to generate license disclaimers with the full license text. There is a copyright statement at the bottom of the README, but that legally (again, not a lawyer) isn't enough for distribution under the MIT license.
How To Reproduce (best to provide workable code or tests!)
Install the npm package in any project and look at the corresponding folder in the node_modules folder. Alternatively, look at the code on npmjs.
PS: Not sure if this is technically a bug or not

@datcat17 we usually show it on the mono repo but makes sense to include it on the distribution. Not a big issue as it is under MIT.
These will be published on our next release in the next 30 days.


require at least one non-numeric character in cashtag

see this post: https://bitclout.com/posts/163c5aca37641a3505821be4cbb31ae5fe0a37c6e8a5d98d1332b46552afe35f

You may want to exclude , or . as the non numeric character required

👏🏼


Reconcile AG connection-info before creating configmap from it

Description
We create an empty configMap on first reconcile, and second reconcile we actually create it with data.
This didn't really cause any issue, as we reconcile multiple times in the initial creation, but still 😅
How can this be tested?
Hard to properly, as the original "issue" is hard to catch (for a split second the ag connection-info configmap is empty).
Just checking that the ag connection-info configmap is created properly.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 64.32%. Comparing base (ee85cbd) to head (2ef0ecf).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##           release-1.3    #3799   +/-   ##
============================================
  Coverage        64.32%   64.32%
============================================
  Files              352      352
  Lines            19002    19002
============================================
  Hits             12223    12223
  Misses            5526     5526
  Partials          1253     1253

Flag
Coverage Δ

unittests
64.32% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add second person rule

I agree, we should use existence to check usage of "I" and "we".

Hmm, my reasoning was for more of a check on consistency, so the predominance of using "I" in a doc, instead of "we". If we just check for existence, then it's not so useful without context, which is not something Vale can do.
Unless I am misunderstanding what you both mean, I kind of see how both could do the same, but the consistency part was my reasoning.

I think I understand your intent better now. The part of the description that says

"I" in single-author articles or "we" in multiple-author articles

could indeed be a candidate for consistency since an article can't be both single- and multi-author.

If we just check for existence, then it's not so useful without context, which is not something Vale can do.

IMO, this is an ideal case for a sub-error level rule (which can selectively disabled): It alerts writers to the fact that, according to the style guide, that they're only supposed to use "I" and "we" in certain contexts without explicitly telling them that they're doing something "wrong" (which they might not be). The alternative (limiting ourselves to precise, error-candidate rules), means we'll end up covering much less of the style guide.

Basically, from my understanding of the discussion so far, we're looking at the two following rules:
extends: consistency
message: 'Use "I" in single-author articles or "we" in multiple-author articles.'
level: error
link: https://www.ibm.com/developerworks/library/styleguidelines/#N10050
either:
  I: we

and
extends: existence
message: 'Only use "%s" when referring to yourself, the author(s).'
level: warning
link: https://www.ibm.com/developerworks/library/styleguidelines/#N10050
tokens:
    - I
    - we

Does this seem right?

Huh, interesting, I think I need to try implementing to see if it matches, but makes sense.
Is "sub-error level rule" an actual thing @jdkato or did you just use that as a description?

By "sub-error" I meant warning or suggestion, which don't result in non-zero return codes.

By "sub-error" I meant warning or suggestion, which don't result in non-zero return codes.

Ah ha, OK, yes, I tend to err on that side of caution for "warnings" anyway.

OK, reminded to get back to this PR


[iOS][Rendering] No way to control size of icon in button (aka action)

Platform

[ ] iOS

Author or host
Host
Version of SDK
2.4.6
Details
There doesn't appear to be any way to control the size of an icon in a button/action. E.g.:
{
    "type" : "AdaptiveCard",
    "$schema" : "http://adaptivecards.io/schemas/adaptive-card.json",
    "version" : "1.3",
    "body" : [
        {
            "type" : "Container",
            "items" : [
                {
                    "type" : "ActionSet",
                    "height": "stretch",
                    "actions" : [
                        {
                            "type" : "Action.Submit",
                            "iconUrl" : "bundle://host/big-heart.png"
                        }
                    ]
                }
            ]
        }
    ]
}

Results in this card:

The actual size of "big-heart.png" is 44x44px. The button is huge (because I set the height to stretch) but the rendered size of the icon is just 27x26pt.
I tried adding ActionsConfig.iconSize to the host config but that had no effect. Neither did ActionsConfig.iconPlacement.
Our card designs often include buttons with an icon and no title, and these icons need to appear at a specific size to match the design.

We need to investigate how this behaves on other platforms to determine the current behavior and what the expected behavior should be.

We need to investigate how this behaves on other platforms to determine the current behavior and what the expected behavior should be.

FWIW we ended up making a custom button type to handle this which replaces Actions/ActionSets entirely.

FWIW we ended up making a custom button type to handle this which replaces Actions/ActionSets entirely.

Pushing it out since the mitigation is available.
@jscalo

@RebeccaAnne,
I removed myself from the assignee since this is a feature request that affects all platforms.

Decision (from #5567) was to match JS behavior: iconSize should always be respected (it will no longer be sized to match text height). Default also changed to 16.


Add rollback verb

My original hope was that we'd get away from an imperative-style interface; bootc edit should allow programmatic targeting for scripting cases.
However, a bootc rollback verb would be highly convenient.

We chatted about this in realtime, I was pushing for a "rollback via targeting previous image tag or sha256 digest" flow.  The problem with doing this via sha256 digest is that many default registry configurations aggressively GC untagged images.
So our entrypoint docs should probably push for a workflow of pushing at least two versioned tags per build, a :latest equivalent and a versioned tag.
This all said, there's still a clear use case and value for the low-level technique of reverting to the previous boot entry; it's particularly needed for cases where networking breaks after upgrade, etc.

Hello,
I'm trying to help out with the support of greenboot with bootc. I had similar thought regarding adding the rollback verb to the CLI. This verb would be a bit crucial for such support on the greenboot side.
Does bootc or ostree native containers keeps (caches) the rollback image? My understanding is that the variant with ostree keeps the deployment in the systems for a rollback. Can that be done in similar way with the bootc-compatible container images (if the idea is to have bootc "engine" agnostic or not having hard dependency on ostree)?
Thank you.
cc @beav

@say-paul My idea was to extend greenboot to use bootc rollback for bootc systems, however the rollback verb is not yet available (this issue) and I've hit the bootloop issue (https://github.com/fedora-iot/greenboot/issues/135). I might try to contribute this verb to bootc, but I'm not sure if Colin's concerns regarding GC is a blocker for that. (And my Rust knowledge is rusty :-)

PR in https://github.com/containers/bootc/pull/447

closed with https://github.com/containers/bootc/pull/447 (?)


Add Multipart tests to Kotlin Okhttp3 Codegen

PR Description
Added Posts Test 4, 6-9 for multipart form testing for Kotlin Okhttp3 Codegen.
Related Issues

Closes #280

Checklist

[x] I have gone through the contributing guide
[x] I have run the tests (flutter test) and all tests are passing

Added/updated tests?

[x] Yes

Refer - https://github.com/foss42/apidash/pull/286#issuecomment-1994811511


How to test multiple languages with firefox?

What are you trying to achieve?
Hi guys, I am trying to test my website in different languages.
Now I get the way to change chrome browser language.
Though I still don't have the way to change it for Firefox. Could you please help? Thank you.
What do you get instead?
After I use the firefox config as below, I can still get the English as the display language of firefox.
My config file for firefox as below:
{
"tests": "./*_test.js",
"timeout": 10000,
"output": "./output",
"helpers": {
"WebDriverIO": {
"url":"https://eatbu.com:8443",
"browser": "firefox",
"coloredLogs": true,
"waitforTimeout": 10000,
"windowSize": "2400x2400",
"desiredCapabilities": {
"mode":"chrome",
"services": ["firefox-profile"],
"firefoxProfile": {"intl.accept_languages": "zh-cn"}
}
}},
"include": {
"I": "./steps_file.js"
},
"bootstrap": false,
"mocha": {},
"name": "CodeceptJS"
}
By the way, here is the working one for chrome:
{
"tests": "./*_test.js",
"timeout": 10000,
"output": "./output",
"helpers": {
"WebDriverIO": {
"url":"https://eatbu.com:8443",
"browser": "chrome",
"coloredLogs": true,
"waitforTimeout": 10000,
"windowSize": "2400x2400",
"desiredCapabilities": {
"browserName": "chrome",
"chromeOptions": {
"args": ["lang=zh-cn"]
}
}
}},
"include": {
"I": "./steps_file.js"
},
"bootstrap": false,
"mocha": {},
"name": "CodeceptJS"
}

OK, I have got the answer. It is from https://github.com/mozilla/geckodriver/blob/master/README.md.
With the great thing from gecoDriver, we can use the following file to make the language change for Firefox:
{
"tests": "./*_test.js",
"timeout": 10000,
"output": "./output",
"helpers": {
"WebDriverIO": {
"url":"https://eatbu.com:8443",
"browser": "firefox",
"coloredLogs": true,
"waitforTimeout": 10000,
"windowSize": "2400x2400",
"desiredCapabilities": {
"browserName":"firefox",
"moz:firefoxOptions": {
"prefs": {
"intl.accept_languages": "zh-cn"
}
}
}
}},
"include": {
"I": "./steps_file.js"
},
"bootstrap": false,
"mocha": {},
"name": "CodeceptJS"
}