QT4CG meeting 171 draft minutes, 7 July 2026

Hi folks,

Here are today’s minutes. Lots of failures in GitHub actions, but I think everything went through. Eventually.

   https://qt4cg.org/meeting/minutes/2026/07-07.html

QT4 CG Meeting 171 Minutes 2026-07-07

   [1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
   Pull Requests

Table of Contents

     * [6]Summary of new and continuing actions [0/9]
     * [7]Draft Minutes
     * [8]1. Administrivia
          + [9]1.1. Roll call [11/11]
          + [10]1.2. Accept the agenda
          + [11]1.3. Approve minutes of the previous meeting
          + [12]1.4. Next meeting
          + [13]1.5. Review of open action items [0/10]
          + [14]1.6. Review of open pull requests and issues
               o [15]1.6.1. Blocked
               o [16]1.6.2. Merge without discussion
               o [17]1.6.3. Close without action
               o [18]1.6.4. Substantive PRs
     * [19]2. Technical agenda
          +
               o [20]2.0.1. PR #2649: 2647 file:descendants: recursion,
                 filtering
               o [21]2.0.2. PR #2717: 2660 fn:matching-segments: named
                 capture groups
               o [22]2.0.3. PR #2753: 2300 fn:doc: determinism rules
               o [23]2.0.4. PR #2755: 2620 fn:unparsed-text: editorial
                 issues
               o [24]2.0.5. PR #2754: 2284 fn:csv-doc, fn:json-doc:
                 Equivalent code, unifications
               o [25]2.0.6. PR #2756: 2705 fn:element-to-map-plan: numeric
                 types
               o [26]2.0.7. PR #2764: 2763 Folds: document possibility of
                 early exiting
               o [27]2.0.8. PR #2747: 2591 Grammar: make step?lookup valid
               o [28]2.0.9. PR #2752: 1697 Add documentary names to
                 callback function signatures
               o [29]2.0.10. PR #2759: 1506 Type declarations: Constructor
                 functions
               o [30]2.0.11. PR #2768: 2740 Drop constructor functions
                 from built-in records
               o [31]2.0.12. PR #2760: 2521 URIs: unify handling of
                 fragment identifiers
               o [32]2.0.13. PR #2766: 2765 Destructuring let: records,
                 array fix
               o [33]2.0.14. PR #2746: 2745 CSV parsing: delimiters
     * [34]3. Any other business
          + [35]3.1. Vacation planning?
          + [36]3.2. Tokenization

Summary of new and continuing actions [0/9]

     * [ ] QT4CG-143-02: MK to try to recover the ability to extract
       formal equivalences into tests
     * [ ] QT4CG-167-01: DB to write a PR for #2641, comments in CSV
     * [ ] QT4CG-167-02: MK to make a PR for #2591, grammar for
       step?lookup is invalid
     * [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on
       bin:decode-string
     * [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the
       functions return JNodes
     * [ ] QT4CG-167-07: NW to review tests for interpolated strings with
       edge cases in mind
     * [ ] QT4CG-167-08: MK to review the state of #1949 to see which
       items are still outstanding.
     * [ ] QT4CG-167-09: NW to close all "nice to have" issues at the end
       of October if they haven't progressed
     * [ ] QT4CG-170-01: RD to draft a proposal that attempts to address
       the lexical issues differently.

Draft Minutes

1. Administrivia

1.1. Roll call [11/11]

     * [X] David J Birnbaum (DB)
     * [X] Reece Dunn (RD)
     * [X] Christian Gr¸n (CG)
     * [X] Joel Kalvesmaki (JK)
     * [X] Michael Kay (MK)
     * [X] Juri Leino (JLO)
     * [X] John Lumley (JWL)
     * [X] Alan Painter (AP)
     * [X] Wendell Piez (WP)
     * [X] Bethan Tovey-Walsh (BTW)
     * [X] Norm Tovey-Walsh (NW) Scribe. Chair.

1.2. Accept the agenda

   Proposal: Accept [37]the agenda.

   Accepted.

1.3. Approve minutes of the previous meeting

   Proposal: Accept [38]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   The next meeting is planned for 14 July.

   JWL gives regrets; WP gives potential regrets.

1.5. Review of open action items [0/10]

     * [ ] QT4CG-143-02: MK to try to recover the ability to extract
       formal equivalences into tests
     * [ ] QT4CG-167-01: DB to write a PR for #2641, comments in CSV
     * [ ] QT4CG-167-02: MK to make a PR for #2591, grammar for
       step?lookup is invalid
     * [ ] QT4CG-167-03: NW to make a PR for #2482, fallback on
       bin:decode-string
     * [ ] QT4CG-167-05: MK to write a proposal to change #2393 so the
       functions return JNodes
     * [ ] QT4CG-167-07: NW to review tests for interpolated strings with
       edge cases in mind
     * [ ] QT4CG-167-08: MK to review the state of #1949 to see which
       items are still outstanding.
     * [ ] QT4CG-167-09: NW to close all "nice to have" issues at the end
       of October if they haven't progressed
     * [ ] QT4CG-170-01: RD to draft a proposal that attempts to address
       the lexical issues differently.

1.6. Review of open pull requests and issues

   This section summarizes all of the issues and pull requests that need
   to be resolved before we can finish. See [39]Technical Agenda below for
   the focus of this meeting.

1.6.1. Blocked

   The following PRs are open but have merge conflicts or comments which
   suggest they aren't ready for action.
     * PR [40]#2638: 2632-6: cross-cutting consistency (automatically
       generated & reviewed)
     * PR [41]#2637: 2632-5: refresh stale 4.0 content (automatically
       generated & reviewed)
     * PR [42]#2636: 2632-4: logic and semantics (automatically generated
       & reviewed)
     * PR [43]#2635: 2632-3: typos and grammar (automatically generated &
       reviewed)
     * PR [44]#2634: 2632-2: fix broken examples in expressions.xml
       (automatically generated & reviewed)
     * PR [45]#2633: 2632-1: fix critical bugs and DTD-validity issues
       (automatically generated & reviewed)
     * PR [46]#2594: 2389 Adaptive Serialization: more freedom
     * PR [47]#2350: 708 An alternative proposal for generators
     * PR [48]#2247: 716 Deferred Evaluation in XPath - the f:generator
       record
     * PR [49]#2160: 2073 data model changes for JNodes and Sequences
     * PR [50]#2071: 77c deep update

1.6.2. Merge without discussion

   The following PRs are editorial, small, or otherwise appeared to be
   uncontroversial when the agenda was prepared. The chairs propose that
   these can be merged without discussion. If you think discussion is
   necessary, please say so.
     * PR [51]#2751: 2674 Editorial Omnibus
     * PR [52]#2744: 2741 Record coercion: keep empty entries
     * PR [53]#2731: 2709 Well-formed sub-documents (2nd attempt)
     * PR [54]#2706: 2704 change path() output for JNodes

   Proposal: Merge these PRs without discussion.

   Accepted.

1.6.3. Close without action

   It has been proposed that the following issues be closed without
   action. If you think discussion is necessary, please say so.
     * Issue [55]#2700: Map constructor: create map entries for items
       other than maps/JNodes
     * Issue [56]#2692: Destructuring inconsistencies and questions
     * Issue [57]#2639: XQuery 4.0: automated review, open questions
     * Issue [58]#2482: Add a fallback function to the `bin:decode-string`
       function

   Proposal: Close these issues without further action.

   Accepted.

1.6.4. Substantive PRs

   The following substantive PRs were open when this agenda was prepared.
     * PR [59]#2768: 2740 Drop constructor functions from built-in records
     * PR [60]#2767: 2750 Make fn:unparsed-text, ... nondeterministic
     * PR [61]#2766: 2765 Destructuring let: records, array fix
     * PR [62]#2764: 2763 Folds: document possibility of early exiting
     * PR [63]#2760: 2521 URIs: unify handling of fragment identifiers
     * PR [64]#2759: 1506 Type declarations: Constructor functions
     * PR [65]#2757: 2569 Rules for unprefixed function calls with
       explicit default function ns
     * PR [66]#2756: 2705 fn:element-to-map-plan: numeric types
     * PR [67]#2755: 2620 fn:unparsed-text: editorial issues
     * PR [68]#2754: 2284 fn:csv-doc, fn:json-doc: Equivalent code,
       unifications
     * PR [69]#2753: 2300 fn:doc: determinism rules
     * PR [70]#2752: 1697 Add documentary names to callback function
       signatures
     * PR [71]#2747: 2591 Grammar: make step?lookup valid
     * PR [72]#2746: 2745 CSV parsing: delimiters
     * PR [73]#2734: 2733 A step too far
     * PR [74]#2719: 1234 Serialization Parameters: Indentation,
       Whitespace, Newlines
     * PR [75]#2717: 2660 fn:matching-segments: named capture groups
     * PR [76]#2715: 2653 FLWOR, member/key/value clauses: allow sequences
     * PR [77]#2714: 2219 Generalize method calls to sequences
     * PR [78]#2713: 2257 Record declarations without namespace
     * PR [79]#2712: 2702 Dynamic node tests
     * PR [80]#2707: 1962 fn:map-to-element
     * PR [81]#2698: 2641 Support comments in csv
     * PR [82]#2696: 2695 Apply templates to maps, arrays, and JNodes
     * PR [83]#2649: 2647 [84]descendants: recursion, filtering
     * PR [85]#2350: 708 An alternative proposal for generators
     * PR [86]#2247: 716 Deferred Evaluation in XPath - the f:generator
       record
     * PR [87]#2761: 2758 Add rules for visibility of named types across
       packages
     * PR [88]#2739: 2738 XSLT - tree terminology

2. Technical agenda

   There are a lot of PRs this week. To close as many as practical, an
   attempt has been made to organize them such that we start with the
   "easy" ones. Proposals to change the order are, uh, in order.

2.0.1. PR #2649: 2647 [89]descendants: recursion, filtering

   See PR [90]#2649
     * CG: We've talked about this before.

   CG walks through the improved prose.
     * CG: I added a rule and changed recurse and filter accordingly.
     * MK: The file path returned is the one provided, not a normalized
       path.
     * CG: This was always underspecified, but BaseX and Saxon do it
       differently.

   Proposal: Accept this PR.

   Accepted.

2.0.2. PR #2717: 2660 fn:matching-segments: named capture groups

   See PR [91]#2717

   Another one we discussed previously.
     * CG: On the question of ASCII for group names, that's all that many
       implementations support.
     * CG: Should we allow positions and name groups?
          + ... My argument was that we can use predicates. I've added
            examples.
     * JLO: I'd like to know why you didn't select the //group.
     * CG: In this case I wanted to make it more explcit.
     * JLO: I think this example would be even nicer if you make one of
       the fields optional, so the numbers change on each example.
     * JK: I like the PR, the predicate tip is really nice.
          + ... To add to JLO's example, it would be nice to see a mixture
            of named and non-named groups.

   Proposal: Accept this PR.

   Accepted.

2.0.3. PR #2753: 2300 fn:doc: determinism rules

   See PR [92]#2753
     * CG: This one is really editorial; we have a stable but it was only
       mentioned in the options. The rules didn't say what the other
       options were.

   Proposal: Accept this PR.

   Accepted.

2.0.4. PR #2755: 2620 fn:unparsed-text: editorial issues

   See PR [93]#2755
     * CG: This was a longstanding issue. We changed the rules for the bin
       and other file functions. Now we have the same rules for encoding
       text everywhere. I've aligned fn:unparsed-text with the other
       functions.
          + ... This may require a few examples to be revised.
     * JWL: The XPath spec now refers to the bin: spec for something
       fairly important. I suppose we've done it for file already in a
       similar way?
     * CG: We had this example before, it has been this way before.
     * JWL: It's a case where we have a fundamental concept that's defined
       by an optional part of the spec.
     * MK: Yes, but you can still refer to the specification.

   Proposal: Accept this PR.

   Accepted.

2.0.5. PR #2754: 2284 fn:csv-doc, fn:json-doc: Equivalent code, unifications

   See PR [94]#2754
     * CG: This changes the *-doc functions so that the rules reflect the
       code that's used in each case.

   Proposal: Accept this PR.

   Accepted.

2.0.6. PR #2756: 2705 fn:element-to-map-plan: numeric types

   See PR [95]#2756
     * CG: The only question is do we want to keep the large pseudocode
       example.
     * MK: I'm inclined to take it out.
     * CG: I'd prefer to drop it.
     * RD: Is it adequately explained in the rules?
     * CG/MK: Yes.
     * CG: I also updated the examples.

   Proposal: Accept this PR.

   Accepted.

2.0.7. PR #2764: 2763 Folds: document possibility of early exiting

   See PR [96]#2764
     * CG: This is a note on possible implementation optimization.
          + ... This is about early exits from a fold if a fixed point
            occurs.
     * MK: Doesn't that example depend on all the values being positive?
     * CG: Yes, but it will work in this example.
     * JLO: To me, the wording is precise enough.
          + ... What's interesting is, what if there's a trace or some
            other side effect?
     * CG: We say if it's deterministic in this case, so trace is
       excluded.

   Proposal: Accept this PR.

   Accepted.

2.0.8. PR #2747: 2591 Grammar: make step?lookup valid

   See PR [97]#2747
     * CG: I checked this with Gunther and he agrees this should be sound.
          + ... You can now use ? without parenthesis in more places.
     * MK: I was slightly surprised how little text is needed to describe
       the semantics, but I couldn't see anything missing.
     * JLO: We had several occasions where we had to distinguish between
       XNodes and JNodes, is this the same here?
     * CG: JNodes aren't relevant here, it's just about the parsing.
     * MK: What about deduplication and document order
     * CG: It will just make (a/b)?c and a/b?c the same.
     * MK: If two things in b both reference an element node c, do you get
       two copies or only one?
     * CG: I think both of these will behave the same way.

   Some further discussion of the semantics of the expression.
     * MK: I'll think about it.

   Proposal: Accept this PR.

   Accepted.

2.0.9. PR #2752: 1697 Add documentary names to callback function signatures

   See PR [98]#2752
     * CG: This adds documentary variable names to higher order functions.
       I made them gray. They're like comments, you can't type them in or
       use them. But it's useful to refer to them in the prose.
     * CG: This simplifies the prose for a lot of functions.
     * JLO: I like it very much, the only question I have is why is it
       $acc instead of $accumulator. (in fn:fold-left).
     * CG: I tried to use short names so that it fits in the tableaux
       better.
     * JWL: It's worth stating somewhere that this doesn't mean they can
       be called by keyword!
     * CG: I think it's mentioned somewhere.
     * MK: It's the system calling these functions, not the user.

   Proposal: Accept this PR.

   Accepted.

2.0.10. PR #2759: 1506 Type declarations: Constructor functions

   See PR [99]#2759
     * CG: I was confused because we have declare type declarations in
       XQuery. We already had constructor functions for some of them.
          + ... I made two versions; in one version I added it to the item
            type declaration section.
          + ... It works quite well for enums and choice items.

   Proposal: Accept this PR.

   Accepted.

2.0.11. PR #2768: 2740 Drop constructor functions from built-in records

   See PR [100]#2768
     * CG: This issue arose from the new syntax of records that have
       optional entries and required entries after that.
          + ... I was never fond of the construtor functions. I think we
            should drop them.
     * CG: This PR also includes a bunch of syntax fixes.
     * CG: You can always coerce a map to the record type and then you'll
       get the record.
     * MK: When I first looked at this, given the way we've defined them,
       none of them needs a constructor function.
          + ... They're mostly the return types of functions.
          + ... At the same time, I'm a bit puzzled by the relationship to
            the previous proposal that adds constructor functions for
            named item types.

   Some discussion of the status of named item types in the specification.
     * MK: At least a couple of them are recursive so I'm not sure how
       that could work.
          + ... It's a little confusing.
     * MK: In the context of this proposal, for all these builtin record
       types, it makes sense not to have a constructor function.
          + ... But I'm not sure where that fits into the general scheme
            of things?
     * NW: Is that a request to wait on this PR?
     * MK: I'm not sure.
     * JLO: I'm also confused. Adding constructor functions for named
       record types and then removing them for record types seems
       inconsistent.
          + ... I'd like to throw in: does that limit us for testing those
            return values?
     * CG: I don't think so because you can always cast a map.
     * JLO: Why don't we want to have constructor functions?
     * CG: The problem is that some record types have required items that
       follow optional items. That's just too hard.
     * MK: I wonder if it makes more sense for the constructor function
       for a record to take a map as its argument.
     * RD: Would make more sense to define the record types in terms of
       the syntax that we've got, rather than saying "here are the rules
       for builtin records and here are the rules for everything else."
          + ... We could end up in a situation like we have for
            fn:concat() that has a special syntax just for the specs.
     * CG: The syntax we currently use is a syntax that you can also use
       in writing queries, so there shouldn't be a difference.
     * RD: Whatever behavior that has with respect to builtin functions
       should apply here.

   CG invites suggestions for how to design constructor functions for
   builtin record types.

2.0.12. PR #2760: 2521 URIs: unify handling of fragment identifiers

   See PR [101]#2760
     * CG: The question here is how to handle fragment identifiers
       consistently.
          + ... They're optional in fn:doc
     * NW: I think this is the wrong behavior, but that's not relevant to
       making it consistent.
     * MK: The effect was that a previously a fragment identifier was not
       allowed, now it's allowed but implementation defined.
     * CG: Correct.
     * JK: I like the proposal.
     * JLO: I fear that this is an escape hatch to allow all kinds of
       shenanigans with fragment identifiers.
          + ... I'd also be in favor of stronger recommends.

2.0.13. PR #2766: 2765 Destructuring let: records, array fix

   See PR [102]#2766
     * CG: My proposal is to change the way destructuring works for
       recorsds and arrays.
          + ... My proposal is to use the lookup syntax rather than
            map:get for destructuring.

   Proposal: Accept this PR.

   Accepted.

2.0.14. PR #2746: 2745 CSV parsing: delimiters

   See PR [103]#2746
     * CG: This is preparation for CSV serialization. We had wanted to
       make different formats by bidirectional. We don't have a way to
       serialize CSV only parse it.
     * CG: My proposal is to drop the row delimiter. Other languages don't
       provide an option to change the row delimiter.
          + ... Modern CSV parsers already normalize line endings.
     * CG: I think we should rename field-delimitor to separator for
       consistency.
     * RD: Are there any examples of CSV like documents that use the
       control characters for things like start-of-record, end-of-record.
     * CG: We have tests for different row delimiters but we only have
       them for testing.
     * JLO: You mean the control characters "row separator" and "field
       separator". I'm surprised they're not allowed.
     * MK: I'm in favor of this simplification.
     * JLO: Will this be a thing where we decided this in 2026 and we'll
       never go back.
     * WP: To JLO's point, this is about CSV more than it's about Unicode.
       The CSV world hasn't caught up yet.

   Proposal: Accept this PR.

   Accepted.

3. Any other business

3.1. Vacation planning?

     * No meeting first week of August, otherwise business as usual.

3.2. Tokenization

   RD presents his work so far on tokenization.
     * NW: Is this intended to be a change to normative prose?
     * RD: Yes.

References

   1. https://qt4cg.org/meeting/minutes/
   2. https://qt4cg.org/
   3. https://qt4cg.org/dashboard
   4. https://github.com/qt4cg/qtspecs/issues
   5. https://github.com/qt4cg/qtspecs/pulls
   6. https://qt4cg.org/meeting/minutes/2026/07-07.html#new-actions
   7. https://qt4cg.org/meeting/minutes/2026/07-07.html#minutes
   8. https://qt4cg.org/meeting/minutes/2026/07-07.html#administrivia
   9. https://qt4cg.org/meeting/minutes/2026/07-07.html#roll-call
  10. https://qt4cg.org/meeting/minutes/2026/07-07.html#agenda
  11. https://qt4cg.org/meeting/minutes/2026/07-07.html#approve-minutes
  12. https://qt4cg.org/meeting/minutes/2026/07-07.html#next-meeting
  13. https://qt4cg.org/meeting/minutes/2026/07-07.html#open-actions
  14. https://qt4cg.org/meeting/minutes/2026/07-07.html#open-pull-requests
  15. https://qt4cg.org/meeting/minutes/2026/07-07.html#blocked
  16. https://qt4cg.org/meeting/minutes/2026/07-07.html#merge-without-discussion
  17. https://qt4cg.org/meeting/minutes/2026/07-07.html#close-without-action
  18. https://qt4cg.org/meeting/minutes/2026/07-07.html#substantive
  19. https://qt4cg.org/meeting/minutes/2026/07-07.html#technical-agenda
  20. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2649
  21. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2717
  22. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2753
  23. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2755
  24. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2754
  25. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2756
  26. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2764
  27. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2747
  28. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2752
  29. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2759
  30. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2768
  31. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2760
  32. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2766
  33. https://qt4cg.org/meeting/minutes/2026/07-07.html#pr-2746
  34. https://qt4cg.org/meeting/minutes/2026/07-07.html#any-other-business
  35. https://qt4cg.org/meeting/minutes/2026/07-07.html#h-343C597D-9C18-4FAC-8AD1-FD47D867A128
  36. https://qt4cg.org/meeting/minutes/2026/07-07.html#h-6C709A88-8309-4DF8-A6D8-5A9642CD9DB5
  37. https://qt4cg.org/meeting/agenda/2026/07-07.html
  38. https://qt4cg.org/meeting/minutes/2026/06-30.html
  39. https://qt4cg.org/meeting/minutes/2026/07-07.html#technical-agenda
  40. https://qt4cg.org/dashboard/#pr-2638
  41. https://qt4cg.org/dashboard/#pr-2637
  42. https://qt4cg.org/dashboard/#pr-2636
  43. https://qt4cg.org/dashboard/#pr-2635
  44. https://qt4cg.org/dashboard/#pr-2634
  45. https://qt4cg.org/dashboard/#pr-2633
  46. https://qt4cg.org/dashboard/#pr-2594
  47. https://qt4cg.org/dashboard/#pr-2350
  48. https://qt4cg.org/dashboard/#pr-2247
  49. https://qt4cg.org/dashboard/#pr-2160
  50. https://qt4cg.org/dashboard/#pr-2071
  51. https://qt4cg.org/dashboard/#pr-2751
  52. https://qt4cg.org/dashboard/#pr-2744
  53. https://qt4cg.org/dashboard/#pr-2731
  54. https://qt4cg.org/dashboard/#pr-2706
  55. https://github.com/qt4cg/qtspecs/issues/2700
  56. https://github.com/qt4cg/qtspecs/issues/2692
  57. https://github.com/qt4cg/qtspecs/issues/2639
  58. https://github.com/qt4cg/qtspecs/issues/2482
  59. https://qt4cg.org/dashboard/#pr-2768
  60. https://qt4cg.org/dashboard/#pr-2767
  61. https://qt4cg.org/dashboard/#pr-2766
  62. https://qt4cg.org/dashboard/#pr-2764
  63. https://qt4cg.org/dashboard/#pr-2760
  64. https://qt4cg.org/dashboard/#pr-2759
  65. https://qt4cg.org/dashboard/#pr-2757
  66. https://qt4cg.org/dashboard/#pr-2756
  67. https://qt4cg.org/dashboard/#pr-2755
  68. https://qt4cg.org/dashboard/#pr-2754
  69. https://qt4cg.org/dashboard/#pr-2753
  70. https://qt4cg.org/dashboard/#pr-2752
  71. https://qt4cg.org/dashboard/#pr-2747
  72. https://qt4cg.org/dashboard/#pr-2746
  73. https://qt4cg.org/dashboard/#pr-2734
  74. https://qt4cg.org/dashboard/#pr-2719
  75. https://qt4cg.org/dashboard/#pr-2717
  76. https://qt4cg.org/dashboard/#pr-2715
  77. https://qt4cg.org/dashboard/#pr-2714
  78. https://qt4cg.org/dashboard/#pr-2713
  79. https://qt4cg.org/dashboard/#pr-2712
  80. https://qt4cg.org/dashboard/#pr-2707
  81. https://qt4cg.org/dashboard/#pr-2698
  82. https://qt4cg.org/dashboard/#pr-2696
  83. https://qt4cg.org/dashboard/#pr-2649
  84. https://qt4cg.org/meeting/minutes/2026/descendants
  85. https://qt4cg.org/dashboard/#pr-2350
  86. https://qt4cg.org/dashboard/#pr-2247
  87. https://qt4cg.org/dashboard/#pr-2761
  88. https://qt4cg.org/dashboard/#pr-2739
  89. https://qt4cg.org/meeting/minutes/2026/descendants
  90. https://qt4cg.org/dashboard/#pr-2649
  91. https://qt4cg.org/dashboard/#pr-2717
  92. https://qt4cg.org/dashboard/#pr-2753
  93. https://qt4cg.org/dashboard/#pr-2755
  94. https://qt4cg.org/dashboard/#pr-2754
  95. https://qt4cg.org/dashboard/#pr-2756
  96. https://qt4cg.org/dashboard/#pr-2764
  97. https://qt4cg.org/dashboard/#pr-2747
  98. https://qt4cg.org/dashboard/#pr-2752
  99. https://qt4cg.org/dashboard/#pr-2759
 100. https://qt4cg.org/dashboard/#pr-2768
 101. https://qt4cg.org/dashboard/#pr-2760
 102. https://qt4cg.org/dashboard/#pr-2766
 103. https://qt4cg.org/dashboard/#pr-2746


--
Norm Tovey-Walsh
CEO, Saxonica

Received on Tuesday, 7 July 2026 18:40:20 UTC